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ABSTRACT 

This  thesis  is  a  detailed  design  of  a  security  kernel 
for  an  archival  file  storage  system.  Microprocessor 
technology  is  used  to  address  a  major  part  of  the  problem 
of  information  security  in  a  distributed  computer  system. 
Utilizing  multiprogramming  techniques  for  processor 
efficiency,  segmentation  for  controlled  sharing,  and  a 
loop-free  structure  for  avoiding  intermodule  dependencies, 
the  Archival  Storage  System  is  designed  for  implementation 
on  the  Zilog  Z8F01  microprocessor  with  a  memory  management 
unit.  The  concepts  of  a  process  structure  and  a 
distributed  kernel  are  used  in  providing  management  of  the 
shared  hardware  resources  of  the  system.  The  security 
kernel  primitives  create  a  virtual  machine  environment  and 
provide  information  security  in  accordance  with  a 
non-discretionary  security  policy. 
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I.   INTRODUCTION 

This  detailed  design  of  a  security  kernel  provides  a 
basis  for  implementation  of  an  archival  file  storage 
operating  system.  The  system  is  intended  to  store  files 
for  an  array  of  computer  hosts  at  multiple  information 
security  levels.  The  design  presents  algorithms  and  data 
structures  which  can  be  implemented  on  microprocessor 
hardware  available  today,  to  provide  economical  and  secure 
storage.  Controlled  sharing  of  information  and  multilevel 
security  were  the  key  design  goals.  Multiprogramming  is 
the  technique  used  to  improve  efficiency  of  the  system 
which  is  primarily  performing  input  and  output  operations. 
A  loop-free  structure  is  used  to  avoid  undesirable 
dependency  loops  [l] .  This  allows  modules  to  be  changed 
without  introducing  changes  in  other  modules. 

There  are  two  components  of  the  Archival  Storage 
System:  1)  the  Supervisor  and  2)  the  Security  Kernel  [2]. 
The  Supervisor  (the  subject  of  separate  research  [3]) 
supports  all  user  services:  1)  hierarchical  file  system, 
2)  discretionary  access  controls,  and  3)  protocols  for 
communication.  The  Supervisor  operates  outside  the  Kernel 
domain  on  a  virtual  machine  created  by  the  Kernel 
primitives.  The  Supervisor's  privilege-restricted  domain 
has  access  only  to  a  subset  of  the  machine  instructions, 
thus  needing  the  Kernel  primitives  to  accomplish  tasks 
such  as  input  or  output. 

The   Security  Kernel  described  in  this  thesis  manages 
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the  real  resources  of  the  hardware  system:  1)  memory,  2) 
microprocessor,  3)  external  devices,  and  4)  input/output 
ports.  It  is  also  responsible  for  mediating  all 
non-discretionary  access  to  information.  The  Kernel 
operates  in  the  most  privileged  domain  of  the  machine  and 
therefore  has  access  to  all  machine  instructions. 

A.   BACKGROUND 

Microprocessors  have  become  affordable,  prolific,  and 
powerful  computing  resources.  The  result  of  these 
attributes  is  the  use  of  microprocessors  in  applications 
previously  requiring  much  larger  and  more  expensive 
processors.  Additionally,  new  applications  which  can  now 
be  economically  computerized  are  being  seriously  explored. 

Conversely,  software  has  become  more  costly. 
Microprocessor  operating  systems  and  applications  programs 
continue  to  be  highly  specialized,  thus  failing  to 
reasonably  exploit  the  potential  of  the  microprocessor. 
The  specialization  of  software  for  microprocessors  also 
perpetuates  problems  such  as  I/O  format  incompatibilities 
which  occur  when  information  exchange  among  processors  is 
desired. 

Information  security  on  microprocessors  has  been 
completely  ignored  to  date,  or  handled  with  ad-hoc 
attempts  at  a  solution.  However,  this  issue  is  becoming 
increasingly  important  as  the  uses  of  microprocessors 
continue  to  be  expanded.  For  example,  the  Department  of 
the   Navy   is   investigating  the  use  of  microprocessors  on 
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small  ships  for  automating  shipboard  administrative 
functions  [4]  .  Information  security  for  such  functions  is 
a  major  requirement  which  cannot  presently  be  met. 

Proposing  a  solution  to  the  above  problems,  a 
high-level  design  for  a  secure  operating  system  for 
microprocessor-based  systems  has  been  outlined  by 
O'Connell  and  Bichardson  [5].  The  design  goals  of  that 
operating  system  were  configuration  independence, 
distributed  processing,  multiple  protection  domains, 
multiprocessing,  and  multiprogramming.  Because  such  a 
broad,  general  operating  system  is  not  always  reauired, 
the  design  provided  for  a  family  of  operating  systems.  A 
family  member  could  use  a  subset  of  functions  for  a 
specific  application  while  allowing  later  extensions.  This 
thesis  presents  the  detailed  design  for  such  a  family 
member . 

B.   BASIC  CONCEPTS 

The  Archival  Storage  System  can  be  the  nucleus  of  a 
secure,  distributed  multiprocessor  system.  It  provides 
'data  warehouse*  facilities  for  multiple  host  computers  in 
the  network.  A  host  may  be  operating  at  a  single  security 
level,  or  simultaneously  at  several  security  levels 
without  affecting  the  Archival  Storage  System.  Information 
storage  with  multilevel  security  is  provided  for  each  host 
connected  to  a  port  of  the  warehouse.  Additionally,  the 
data  warehouse  is  the  mechanism  for  providing  controlled 
sharing  among  the  hosts.  Thus,  we  can  apply  microprocessor 
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technology   to   address   a  significant  part  of  the  larger 
multilevel  security  problem  [6]  for  distributed  systems. 

A  subset  of  the  O'Connell  and  Richardson  design  has 
been  selected  as  the  basis  for  the  detailed  design  of  the 
Archival  Storage  System.  (The  subset  chosen  omits  the 
provisions  for  multiprocessors,  dynamic  linking,  demand 
segmentation,  "transient"  processes,  and  a  user  domain.) 
The  Supervisor,  protocols,  and  interfaces  to  the  host 
computers  are  presented  in  a  parallel  thesis  by  Parks  [3] 
while  detailed  design  of  the  Security  Kernel  is  presented 
in  this  thesis. 

There  are  two  components  of  the  Archival  Storage 
System  Security  Kernel  which  reside  in  the  privileged 
domain  of  the  machine:  l)the  distributed  kernel  and  2)  the 
kernel  processes.  From  a  logical  view,  some  kernel 
procedures  are  distributed  among  all  the  Supervisor 
processes  in  the  system,  with  the  remaining  procedures 
forming  kernel  processes.  These  kernel  processes  perform 
functions  that  are  asynchronous  to  the  supervisor 
processes  and  are  responsible  for  the  shared  resources  of 
the  system  (processes,  processor,  memory,  input/output). 

1 .   Definition  of  a  Process 

A  sequential  process  can  be  conceptualized  as  an 
execution  point  and  an  address  space  which  is  a  logical 
rather  than  physical  entity.  All  procedures  that  are  in 
the  flow  (or  locus)  of  control  are  in  the  address  space. 
In  a  distributed  operating  system,  the  locus  of   execution 
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includes  those  operating  system  functions  which  are 
logically  part  of  the  user  process.  The  distributed 
operating  system  is  divided  into  procedures  which  are 
called  in  normal  fashion,  hut  are  located  in  the 
privileged  domain. 

2.   Multiple  Protection  Domains 

One  requirement  for  design  of  a  security  kernel  is 
isolation  of  the  kernel  procedures  to  make  them 
tamperproof.  A  way  this  can  be  achieved  is  to  arrange  the 
process  address  space  into  hardware  or  software  protection 
domains.  Domains  need  not  be  hierarchical,  but  in  this 
case  they  are.  Hierarchical  domains  are  commonly  called 
protection  rings  [?]  . 

3ach  level  in  the  hierarchy  is  more  privileged 
than  the  preceding  level.  In  the  Archival  Storage  System 
only  two  domains  are  necessary.  Other  levels  must  be  added 
to  protect  the  Supervisor  if  the  design  is  extended  to 
include  user  applications.  The  distributed  Kernel  resiles 
in  the  most  privileged  domain  and  may  access  any  segment 
within  the  address  space  of  a  process.  All  systemwide 
databases  are  in  the  kernel  domain.  Violation  of  the 
confinement  principle  described  by  Lampson  [9]  and  Lipner 
[9]  would  occur  if  such  information  could  be  passed  to 
other  domains. 

ThP  Supervisor  operates  in  the  outer  or  least 
privileged  protection  domain  where  access  to  segments  ani 
external  devices  is  restricted.  Only  those  databases  which 
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are  'process  local"  may  be  accessed.  This  does  not  prevent; 
sharing  since  different  segment  numbers  and  access  rights 
for  each  process  can  be  interpreted  and  enforced  by  the 
kernel.  Each  Supervisor  process  is  required  to  remain  at  a 
specified  security  level  within  its  domain. 

Protection  domains  may  be  created  by  either 
hardware  or  software.  Software  implementations  of 
protection  domains  (as  in  the  early  Multics  [10])  are 
feasible,  but  result  in  a  degradation  of  efficiency.  This 
performance  loss  is  unacceptable  in  many  applications.  In 
large  processors  a  hardware  ring  mechanism  is  sometimes 
used  to  provide  the  implementation  [7]  .  This  general  ring 
mechanism  is  not  available  in  current  microprocessors,  but 
two  domain  machines  are  available.  When  supplemented  by 
ring-crossing  software,  this  will  provide  the  desired 
multiple  domains. 

3 .   Segmentation 

A  segment  is  defined  as  a  logical  grouping  of 
information  [11],  while  segmentation  is  a  technique  for 
managing  segments  within  an  address  space.  A  process's 
address  space  consists  of  a  collection  of  procedures  and 
data  segments.  All  address  specifications  require  the 
segment  specification  and  the  offset  within  the  segment 
(i.e.,  a  two-dimensional  address).  Segments  are  therefore 
distinctly  visible  to  the  user.  Unlike  pages,  segments  are 
arbitrarily  sized  and  logical  units  with  logical 
attributes  to  d°scribe  them. 
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Attributes  of  segments  are  contained  in  a 
structure  called  a  segment  descriptor.  The  descriptor 
associates  segments  with  address  in  memory,  size,  and 
access  allowed.  Maintaining  all  of  the  descriptors  of  the 
segments  of  a  process  in  a  descriptor  list  allows  the 
address  space  of  the  process  to  he  easily  managed. 

Segmentation  offers  benefits  as  a  memory 
management  scheme.  The  key  advantage  is  the  ability  of 
multiple  processes  to  share  segments  without  the 
requirement  of  maintaining  multiple  copies  in  memory. 
Cther  favorable  characteristics  of  segmentation  are 
control  of  memory  waste  due  to  fragmentation,  creation  of 
user  virtual  memory,  dynamic  linking  of  modules,  and 
enforcement  of  controlled  segment  access. 

Segmentation  eliminates  the  need  to  duplicate  a 
segment  when  shared.  Having  only  one  copy  saves  memory  and 
eliminates  the  problem  of  conflicting  data  which  occurs 
when  multiple  copies  are  maintained.  Even  more  central  to 
segmentation  is  the  ability  of  cooperating  processes  to 
communicate  with  each  other  through  shared  segments. 
Inter-process  synchronization  and  communication  are 
necessary  functions  in  a  multiprogramming  environment. 
4.   Information  Security 

Most  users  of  computer  systems  are  required  to 
safeguard  information  from  unauthorized  access.  Examples 
abound:  government  (classified  information),  corporations 
(trade  secrets),  banking  (electronic  funds  transfer),   and 
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all  users  of  personal  data  (privacy  act).  This  reauirement 
is  not  relaxed  when  microprocessors  are  used  instead  of 
(or  in  support  of)  large  computer  systems.  Dedicating  a 
device  to  a  specific  security  level  (dedicated  mode)  [6] 
is  a  method  commonly  used  to  meet  the  security 
requirement.  This  solution  is  unsatisfactory  for  any  user 
with  a  reauirement  to  utilize  data  at  more  than  one  access 
class  . 

Another  solution  to  the  problem  of  accessing 
information  at  different  security  levels  is  to  operate  in 
the  multilevel  mode.  In  this  case  both  users  and 
information  at  different  security  classes  exist 
simultaneously  on  the  same  computer  system.  Users  are  not 
permitted  to  access  information  unless  authorized  by  the 
security  policy  in  effect. 

In  the  dedicated  mode  all  security  measures  are 
external  to  the  computer  system  (e.g.,  perimeter  fencing, 
guards,  door  locks,  etc.).  When  a  multilevel  mode 
environment  is  used,  controls  must  be  internal  as  well  as 
external.  Attempts  at  internal  controls  have  been  tried  by 
adding  security  measures  to  existing  systems  with 
unsatisfactory  results.  Numerous  cases  are  documented  of 
penetrations  (i.e.,  unauthorized  access)  of  these  systems 
[6].  Intuition  rather  than  sound  design  was  the 
methodology  used  in  these  unsuccessful  attempts  at 
securi  ty . 

Internal   controls   nust  be  designed  into  a  system 
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from  its  conception.  The  approach  to  designing  these 
controls  is  the  security  kernel  methodology .  The  first 
step  using  the  security  kernel  methodology  is  to  define 
the  security  requirements.  From  this  definition  a 
conceptual  design  is  created.  The  conceptual  design  is 
actually  a  mathematical  model  which  can  be  rigorously 
proven  and  provides  the  basis  for  testing  (certifying)  [2] 
all  subsequent  implementations. 

Three  things  are  reauisite  before  a  system  can  be 
secure  using  the  security  kernel  concept:  1)  The  kernel 
must  be  isolated  cr  tamperproof.  Obviously  if  a  penetrator 
can  change  the  kernel  software,  then  the  behavior  of  the 
kernel  can  be  modified.  2)  The  kernel  must  be  invoked  on 
every  attempt  to  access  information.  This  requirement  can 
be  met  by  initial  software  interpretation  of  access  on  the 
first  call  to  a  segment.  Thereafter,  hardware  can  enforce 
the  access  criteria.  3)  The  kernel  must  be  subject  to 
certification.  Proof  of  the  mathematical  model  must  be 
followed  by  thorough  testing  of  the  implementation  to 
insure  that  each  input  yields  the  desired  output.  Since 
hardware  and  software  are  involved,  both  must  be  tested 
before  the  kernel  car.  be  certified. 

As  previously  stated,  the  first  step  in  the  design 
of  the  secure  computer  system  is  to  define  the  security 
requirements.  A  properly  designed  computer  system  is  then 
secure  with  respect  to  that  definition  or  policy.  A 
security  policy  consists  of  the  external  laws,  rules,   and 
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regulations  that  establish  what  access  is  to  be  permitted. 
Two  distinct  types  of  security  policy  exist:  1) 
non-discretionary  and  2)  discretionary. 

Non-discretionary  policy  involves  comparing  the 
requested  (i.e.,  the  information  object's)  access  class 
(oac)  with  the  access  class  of  the  requestor  (i.e.,  the 
subject)  (sac)  to  insure  that  they  are  compatible.  For 
example,  in  the  Department  of  Defense  security  policy  a 
secret  cleared  individual  (subject)  may  have  access  to 
documents  (objects)  which  are  classified  as  secret, 
confidential,  or  unclassified. 

The  relationships  between  different  access  classes 
can  be  represented  by  a  lattice  structure  [12].  This 
lattice  structure  is  totally  ordered  if  all  classes  are 
related.  When  the  classes  are  either  related  or  disjoint 
the  lattice  is  partially  ordered.  The  lattice  structure 
interprets  the  authorized  access  based  on  the 
relationships  between  two  labels.  The  lattice  structure 
abstraction  is  important  because  it  seems  to  represent 
most  practical  security  policies.  By  changing  the 
interpretation  of  labels  in  the  non-discretionary  security 
module,  a  different  policy  can  be  implemented  so  that,  for 
example,  Privacy  Act  requirements  are  as  enforceable  as 
Department  of  Defense  security  policies. 

The  following  interpretation  defines  the  access 
permitted  in  a  computer  system  (where  "%  is  defined  to 
mean  unrelated)  in  terms  of  subject  access  class  (sac)  and 
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object  access  class  (oac): 

sac  =  oac,  read/write  permitted 
sac  >  oac ,  read  permitted  (read  down) 
sac  <  oac,  write  permitted  (write  up) 
sac  %    oac,  no  access 
DOD  security  policy  is  represented  by  a  partially   ordered 
lattice   since   security  classifications  are  composed  of  a 
classification   level   and  a   category   (e.g.,    secret, 
cryptographic  or  confidential,  nuclear). 

Discretionary  controls  provide  a  refinement  of  the 
non-discretionary  access.  A  common  example  of 
discretionary  controls  involves  checking  an  access  control 
list  before  allowing  an  access.  This  allows  authorized 
subjects  ; users)  to  specify  who  may  use  that  segment 
within  the  confines  of  the  non-discretionary  policy.  The 
DOD  "need-to-know"  rule  is  an  example  of  discretionary 
policy.  In  the  Archival  Storage  System  non-discretionary 
policy  is  enforced  by  the  Supervisor,  based  on  both  the 
host  and  the  user. 

C.   STRUCTURE  CF  TEE  THESIS 

This  thesis  presents  the  detailed  design  of  a  portion 
of  the  security  kernel  for  an  archival  file  storage 
facility  (distributed  kernel  procedures  and  memory  manager 
process).  Levels  of  abstraction  are  used  to  reduce  the 
complexity  of  the  hierarchical  Archival  Storage  System. 
Level  2  contains  the  Supervisor  and  operates  in  the 
virtual   environment  created  by  the  Kernel.  The  Supervisor 
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does  not  control  the  hardware  of  the  system  but  applies 
the  hardware  resources  only  by  appealing  to  the  functions 
of  the  Kernel.  Calls  to  procedures  at  different  levels  may 
only  be  made  in  a  downward  direction  and  corresponding 
returns  only  in  an  upward  direction  (i.e.,  the  Kernel  ^ay 
not  call  upon  the  Supervisor  to  accomplish  any  task).  This 
restriction,  rigidly  enforced  at  all  levels  of  abstraction 
in  the  design,  reduces  the  number  and  type  of  interactions 
of  the  system. 

Figure  1  shows  the  process  structure  of  the  system 
with  the  distributed  and  non-distributed  kernel.  The 
asynchronous  Memory  Manager  and  I/O  Manager  are  kernel 
processes.  The  remaining  kernel  procedures  are  distributed 
in  all  the  supervisor  processes. 

In  the  next  chapter  the  details  of  the  design  are 
presented.  Although  this  is  not  an  implementation,  the 
Zilog  ZS001  Microprocessor  [13]  with  the  Z6010  MMU  Memory 
Management  Unit  is  used  as  the  hardware  base  for  this 
research.  Choices  made  during  the  design  process  were 
often  influenced  by  the  hardware  features  available.  The 
Z6000  family  of  devices  is  not  mandatory  for  implementing 
the  Archival  Storage  System.  Cther  microprocessors  exist 
which  are  capable  of  supporting  a  secure  system. 

Algorithms  and  data  structures  are  presented  in  the 
high  level  language  PLZ/SY5  [14] .  PLZ/SY5  is  a 
Pascal-like,  block-structured  language.  Designed  by  Zilog, 
the   language   can   be  compiled  to  Z6000  instruction  cole. 
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PLZ/ASM  [15]  is  used  where  machine  level  instructions  for 
direct  hardware  manipulation  are  required.  These  two 
languages  for  the  Z8000  are  used  because  of  the  capability 
of  linking  modules  of  either  language  to  the  other. 
Additionally,  PLZ/ASM  has  the  same  high  level  data 
structures  and  structured  control  mechanisms  present  in 
PLZ/SYS. 

The  conclusions  reached  during  this  research  are 
presented  in  the  last  chapter.  Topics  for  further  research 
and  implementation  are  identified,  including  those  in  the 
area  of  secure  systems.  With  this  multilevel  data-store,  a 
secure  distributed  microprocessor  system  can  be 
implemented  using  communications  lines  to  interface 
distributed  processors  of  the  network  to  the  "data 
warehouse ." 
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II.   DETAILED  DESIGN 

A.   HARDWARE  REQUIREMENTS 

Theoretically  any  processor  hardware  is  usable  for 
secure  computer  systems.  However,  in  practice  certain 
hardware  features  are  essential  for  efficiency.  In 
addition,  complexity  of  the  software  portion  of  the 
security  kernel  is  highly  dependent  upon  the  capabilities 
of  the  hardware.  Because  simplification  of  the  kernel 
results  in  an  easier  proof  of  correctness,  it  is 
worthwhile  to  use  additional  hardware  to  achieve  security. 

One  essential  hardware  feature  is  a  segmentation 
mechanism.  Segmentation  allows  the  use  of  one  uniform  type 
of  information  object,  the  segment.  Kernel  software  which 
deals  with  logical  objects  is  then  simplified.  Paging 
hardware  without  segmentation  does  not  provide  a  correct 
structure  for  objects,  since  pages  are  physical  objects 
with  physical  attributes.  For  example,  an  access  risht  is 
a  logical  attribute.  Applying  an  access  right  to  a 
physical  object  ''as  is  the  case  for  ISM  370  protection 
"locks"  [11])  obscures  the  purpose  of  the  attribute,  is 
out  of  context,  and  adds  complexity  to  the  supporting 
mechanism . 

A  segment  address  consists  of  a  segment  name  and  an 
offset  within  the  segment.  This  logical  address  must  be 
transformed  into  an  absolute  address  before  it  can  be 
used.  While  software  is  capable  of  making  this 
transformation,   hardware   can   perform   the   mapping  more 
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efficiently  and  simultaneously  check  access  while  doing 
the  mapping. 

Multiple  execution  domains  are  also  considered 
essential  in  hardware.  This  feature  is  used  in  current 
computer  systems  to  protect  the  operating  system  from 
applications  programs,  hut  until  recently  this  feature  has 
not  been  available  in  microprocessor  hardware.  In  the 
initial  Archival  Storage  System  implementation  only  two 
domains  are  necessary  since  applications  programs  do  not 
exist  inside  the  boundaries  of  the  system.  Protecting  the 
Kernel  from  the  Supervisor  is  the  only  domain  protection 
required.  If  user  utilities  are  added  to  the  design,  then 
another  domain  will  be  necessary  to  protect  the  Supervisor 
from  user  tampering. 

With  the  introduction  of  Zilog's  ZS000,  the  above 
hardware  features  are  available  in  the  microprocessor 
category.  The  design  of  the  Archival  Storage  System  is 
targeted  toward  a  hardware  system  based  upon  the  28001 
segmented  microprocessor  [16]  and  the  ZS010  MMU  Memory 
Management  Unit  [17].  The  ZS001  is  a  16-bit  two-domain 
microprocessor  which  produces  a  23-bit  segmented  address. 
The  ZS010  MMU  maps  the  23-bit  logical  address  into  a 
24-bit  absolute  address  and  allows  the  capability  of 
addressing  up  to  128  segments  of  64K  bytes  each  in  the 
two-dimensional  memory  space. 

In  addition  to  the  address  mapping  hardware,  the  MMU 
also  provides  memory  access  protection.  Segment  access  may 
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be  set  to  write  (read  implied),  read,  or  execute  only. 
When  an  unauthorized  access  is  attempted,  the  MMU  prevents 
the  access,  then  sends  a  trap  (or  fault)  signal  to  the 
microprocessor.  A  trap  is  an  internal  interrupt  which  is 
synchronous  rather  than  asynchronous  to  the  cycling  of  the 
processor  and  must  he  resolved  by  the  processor  before 
processing  can  continue. 

The  microprocessor  also  supports  two  protection 
domains.  The  MMU  provides  the  implementation  of  two 
hardware  rings  by  checking  for  system  or  user  status  on 
each  access  to  a  segment.  The  bit  in  the  MMU  which 
specifies  system  or  normal  mode,  thus  specifies  which 
segments  are  accessible  in  just  the  Kernel  ring  and  which 
segments  are  also  accessible  in  the  Supervisor  ring.  Thus 
a  process  must  cross  into  the  Kernel  ring  to  access  the 
Kernel  primitives.  If  more  than  two  rings  are  required,  an 
additional  MMU  (up  to  eight  total)  may  be  employed  per 
ring. 

The  hardware  also  supports  resource  control  by 
limiting  the  use  of  certain  machine  instructions.  In  the 
system  mode  all  machine  instructions  can  be  executed.  When 
in  user  mode,  the  hardware  will  not  allow  the  use  of 
input/output  instructions,  certain  machine  control 
instructions,  or  special  input/output  instructions  (used 
to  load  and  control  the  MMU).  Thus  the  Kernel  can  control 
the  microprocessor,  the  main  memory  (through  the  MMU),  and 
all  external  devices. 
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Hardware  features  other  than  those  described  above  are 
indicated  from  a  performance  standpoint.  For  instance,  a 
direct  memory  access  (DMA)  device  could  make  memory  to 
memory,  memory  to  port,  or  port  to  memory  transfers  faster 
than  similar  transfers  under  direct  CPU  control.  This 
would  allow  the  CPU  to  continue  with  other  tasks  while  the 
DMA  is  processing  the  data  transfers.  Protection  of  memory 
can  still  be  realized  by  routing  the  DMA  through  the  MMU. 
The  DMA  would  have  to  be  "smart"  enough  to  handle  an 
access  violation  trap  or  the  Kernel  would  have  to 
guarantee,  by  MMU  set-up,  that  the  DMA  would  not  violate 
the  security  policy.  This  type  of  hardware  is  not  crucial 
to  the  design  at  this  level,  and  the  decision  on  its  use 
is  left  to  the  implementor. 

The  MMU  does  lack  a  descriptor  base  register 
capability  [10].  Process  switches  without  this  facility 
require  at  least  selective  unloading  and  loading  of  the 
descriptor  registers  in  the  MMU,  and  a  process  switch 
would  take  roughly  two  (2)  milliseconds  to  accomplish  in 
this  manner.  It  is  evident  that  process  switching  may  lead 
to  thrashing  problems  if  done  too  often.  There  are  ways 
the  implementor  might  avoid  this  problem  (e.g.,  dedicating 
an  MMU  to  each  process,  then  switching  MMUs  rather  than 
loading/unloading  a  single  MMU). 

3.   PROPOSED  K2PNEL  DESIGM 
1 .   Notation 

Notation   is   important    in   making   algorithms 
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understandable.  It  should  not,  however,  require  more 
thought  to  understand  the  notation  than  the  central 
concept.  Since  this  thesis  presents  a  detailed  design,  a 
notation  as  close  as  possible  to  an  actual  language  which 
can  compile  to  ZS000  machine  code  was  desired.  PLZ 
languages  are  used  as  a  notation  to  illustrate  the  data 
structures  and  procedures.  However,  the  code  as  shown  in 
the  figures  cannot  be  directly  implemented.  Among  other 
changes,  procedure  order  has  been  rearranged  to  make 
explanation  of  the  modules  more  logical.  This  change  would 
violate  a  PLZ/SYS  implementation  rule  that  procedures  must 
be  declared  before  they  can  be  invoked. 

The  details  of  the  actual  PLZ/SYS  language 
implementation  may  be  different  from  that  assumed  in  this 
thesis.  In  particular,  the  specific  method  of  parameter 
passing  between  PLZ/ASM  and  PLZ/SYS  is  unknown  at  this 
time.  The  implementor  should  carefully  investigate  how 
passing  of  parameters  in  the  actual  language 
implementation  affects  the  interfaces  between  modules. 

Because  of   the   terminology  used   in   the   ZS000 
Microprocessor   specifications,   the   Supervisor  may  be 
referred  to  as  operating  in  the  normal  or  user  mode. 
the   term   system  mode   is   used,  it  refers  to  the  Kernel 
domain  of  execution. 

2 .   Kernel  Overview 

The  distributed  Kernel  modules  exist  on  three 
levels   (figure   2).  "Each  module  creates  a  different  level 
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of  abstraction  [191.  At  level  1  or  the  innermost  level  is 
the  Inner_Traf f  ic_Controller .  Its  primary  task:  is  the 
control  of  virtual  processors  and  the  multiplexing  of 
virtual  processors  onto  the  real  processor.  The 
Inner_Traf f ic_Controller  uses  the  Virtual  Processor  Table 
as  a  management  tool  for  this  multiplexing  of  virtual 
processors . 

At  level  2  is  the  Traf f ic_Controller .  The 
Traf f ic_Controller  creates  the  sequential  process 
abstraction  [17].  A  process  can  be  in  one  of  two  states: 
1)  blocked  or  2)  unblocked.  When  blocked,  it  must  wait  for 
the  occurrence  of  some  event.  Since  the  process  cannot 
proceed  until  that  event  occurs,  the  virtual  processor  is 
freed  and  then  allocated  to  another  process.  When 
unblocked  a  process  is  either  ready  or  running.  In  the 
ready  state,  the  process  can  run  when  a  virtual  processor 
is  assigned  to  it.  The  readv  state  can  be  entered  from 
either  the  running  or  blocked  state  (figure  3). 

The  Non_Discretionary_Securi ty  Module  is  also  on 
level  2.  This  module  is  charged  with  interpretation  of  the 
security  policy  in  effect.  It  compares  the  two  labels 
which  are  passed  to  it  and  determines  the  relationship  of 
the  labels  based  on  a  lattice  structure  known  to  the 
module.  This  relationship  is  then  used  by  the  kernel  to 
determine  authorized  access  to  objects  (segments  or 
parts).  It  is  emphasized  that  the  Kernel  makes  decisions 
about  access  based  on  relationships  (=,  <,  >,  not  related) 
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and  not  on  the  labels  themselves.  The 
Non_Discretionary_Security  Module  is  the  only  module  in 
the  Kernel  which  makes  any  interpretation  of  security 
labels.  This  allows  most  of  the  practical  security 
policies  to  be  implemented  simply  by  changing  the 
Non_Discretionary_Security  Module. 

At  level  3  is  the  Segment_Manager .  Using  the  MMU 
mapping  to  real  memory  provided  by  the  hardware,  the 
5egment_Manager  creates  a  segmented  virtual  memory  for  the 
process.  Because  of  the  limitations  of  the  hardware  (lack 
of  a  paging  mechanism),  segments  are  not  dynamically 
allocated  real  memory.  The  size  of  a  reauested  segment  is 
fixed  (or  determined)  at  the  time  it  is  created  and  may 
not  change.  The  Supervisor  has  several  options  in  order  to 
handle  the  problem  of  growing  segment  size:  1)  Allocate 
the  maximum  size  to  every  segment  which  is  wasteful  of 
memory,  2)  copy  the  segment  into  a  larger  segment  whenever 
the  size  changes  which  is  wasteful  of  processor  cycles,  3) 
create  a  "super-segment"  as  a  collection  of  segments,  or 
4)  some  combination  of  the  above.  3y  requiring  the 
Supervisor  to  handle  this  problem,  the  initial  Kernel 
implementation  is  simpler. 

The  whole  segment  must  be  swapped  into  main  memory 
in  order  to  be  used.  The  MMU  supports  segments  ranging  In 
size  from  256  bytes  to  64K  bytes  in  multiples  of  256 
bytes.  Additionally,  the  hardware  forces  another 
constraint   on   the  design.  Without  paging,  two  allocation 
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schemes  are  available  to  the  designer:  1)  a  demand 
segmentation  memory  management  scheme  (load  the  segment  Lo 
response  to  a  fault)  or  2)  a  partitioned  allocation 
scheme.  In  this  design  a  partitioned  allocation  scheme  is 
used  to  make  the  Kernel  less  complex.  Part  of  the  burden 
of  memory  management  is  then  forced  on  the  Supervisor.  The 
Supervisor  of  each  process  is  given  a  fixed  amount  of 
linear  "virtual  core*.  Linear  'virtual  core*  is 
distinguished  from  the  two-dimensional  virtual  memory 
created  by  the  segmentation.  The  Supervisor,  by  requests 
to  the  Kernel,  may  fill  virtual  core  with  segments  as  it 
chooses.  The  Supervisor  of  each  process  must  manage  its 
own  virtual  core  and  fit  any  segments  it  uses  within  the 
boundaries  of  this  virtual  core.  The  partitioned 
allocation  portion  of  the  memory  management  scheme  is 
supported  by  the  Memory_Manager  process  of  the 
non-distributed  Kernel. 

The  non-distributed  portion  of  the  Kernel  resides 
in  two  kernel  processes:  1)  Memory_Manager  and  2) 
I/0_Manager.  These  two  processes  are  responsible  for 
actions  which  are  not  logically  part  of  the  supervisor 
processes  because  they  can  function  asynchronously  to  the 
processes.  The  Memory_Manager  moves  segments  within  the 
physical  memory  space  of  the  system.  These  transfers  may 
be  main  memory  to  main  memory,  mam  memory  to  secondary 
storage,  or  secondary  storage  to  main  memory.  Main  memory 
to  main  memory  drives  are  made  because  of  a  design  decision 
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to  restrict  sharing  of  the  same  copy  of  a  segment  unless 
at  least  one  of  the  sharing  processes  has  write  permission 
to  the  segment.  Whenever  two  processes  share  a  segment  and 
neither  has  write  access,  two  copies  of  the  segment  will 
exist — one  in  each  virtual  processor  local  memory.  This 
trade-off  results  in  less  complexity  in  the  kernel  and 
when  the  design  is  expanded  to  a  multiprocessor 
implementation,  bus  contention  is  minimized  [5].  The 
problems  associated  with  the  existence  of  multiple  copies 
in  memory  are  not  present  since  the  segment  is  not 
wr i  teable . 

Whenever  a  segment  is  to  be  shared  and  is 
writeable,  then  the  segment  must  be  moved  to  the  real 
processor  global  memory.  Movement  of  the  segment  is  easily 
accomplished  by  updating  the  appropriate  MMUs  to  reflect 
the  new  location  of  the  segment.  This  concept  of  a  process 
local  and  global  memory  is  analogous  to  processor  local 
and  global  memories  in  multiprocessor  systems.  In  those 
systems,  each  real  processor  owns  a  local  memory,  while 
the  system  controls  the  global  memory  used  by  all 
processors  for  shared  information. 

The  I/0_Manager  is  responsible  for  routing 
segments  across  the  system  boundary,  viz.,  moving  data 
between  external  ports  of  the  system  and  main  memory.  The 
I/0_Manager  does  not  try  to  interpret  the  data,  tut  simply 
provides  a  transfer  service.  All  the  ports  have  specific 
security  classifications  and  are  hard-wired.   This   allows 
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the  I/0_Manager  to  function  without  requiring  labels  or 
other  security  mechanisms  to  determine  access  class. 
Having  all  Hosts  at  a  fixed  security  level  is  a  design 
choice  for  the  .Archival  Storage  System.  Hosts  can  be  at 
multiple  levels  if  the  design  is  modified  to  accept 
"trusted"  labels.  In  the  present  design  the  Host  computer 
is  required  to  be  at  the  level  of  the  port  and  to  handle 
data  consistent  with  the  security  policy  in  effect. 

Since  the  hardware  does  not  completely  support  the 
ring  structure,  software  (Gate_Keeper )  is  needed  for  the 
ring-crossing  mechanism  and  thus  isolation  of  the  Kernel. 
All  calls  to  the  distributed  Kernel  and  interprocess 
communication  with  the  non-distributed  Kernel  from  the 
Supervisor  must  pass  through  the  Gate_Keeper.  The  function 
of  the  Gate_Keeper  is  to  provide  the  sole  entry  point  or 
gate  into  the  Kernel  ring,  validate  the  call  and 
arguments,  and  transfer  the  call  to  the  appropriate  kernel 
module.  If  a  call  is  made  incorrectly  the  Gate_Keeper  sets 
a  return  message  to  an  error  code,  and  returns  without 
further  action.  The  Gate_Keeper  is  the  ring-crossing 
mechanism  of  the  Archival  Storage  System. 
3.   Gate  Keeper  Module 

The  Gate_Keeper  Module  (shown  in  Appendix  A  rather 
than  as  a  figure  because  of  its  length)  consists  of 
procedures  and  primary  data  structures  and  is  the  sole 
entry  point  into  the  Kernel  from  the  Supervisor.  The 
Gate_Keeper   Module   is   written   in  PLZ/ASM  since  it  is  a 
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trap  handler.  (The  user  registers  must  be  saved  when  the 
handler  is  invoked  which  requires  access  to  the  hardware.; 
When  the  Supervisor  wishes  to  invoice  the  Kernel  it  must 
put  the  argument  list  and  space  for  any  return  message  in 
a  segment  with  read/write  access  in  the  Supervisor  ring. 
When  the  system  call  is  made,  the  pointer  to  the  arguments 
is  required  to  he  in  a  double  register.  The  system  call 
instruction  is  then  executed,  with  the  function-code  for 
the  requested  Kernel  procedure  as  a  parameter  within  the 
instruction.  This  causes  the  machine  to  save  the  program 
counter,  flags  and  control  word,  and  the  instruction 
itself  on  the  system  (kernel)  stack.  An  unconditional  jump 
(hardware  initiated)  is  then  made  to  the  Program  Status 
Area  (a  vector  table)  (figure  4)  where  the  machine  state 
for  the  system  call  instruction  is  fetched.  The  Program 
Status  Area  is  established  at  system  generation  and 
consists  of  "frames"  which  contain  the  machine  state  and 
location  of  the  interrupt  and  trap  handlers.  The  processor 
then  begins  execution  in  the  Kernel  ring. 

The  Gate_Keeper  first  saves  the  user  processor 
registers  and  retrieves  the  pointer  to  the  argument  list. 
If  the  argument  list  is  located  in  a  read/write  segment  of 
the  calling  'Supervisor)  ring,  a  copy  of  the  argument  list 


is  put   onto   the   system   stack.   However,   if 


ae   area 


indicated  by  the  calling  ring  is  not  in  the  read/write 
address  space  of  the  process,  the  Gate_Keeper  will  not 
return   an  error   code.  (There  is  no  place  to  return  it!) 
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Figure  4.   Program  Status  Area 


37 


The  Gate_Keeper  restores  the  user  environment  and  makes   a 
normal  return. 

The  Gate_Keeper  uses  a  table  (figure  5)  to  check 
the  range  of  the  function  code.  If  the  3ate_Keeper  cow 
discovers  an  error  during  the  validation  process,  it  sets 
the  return  message  to  an  error  code,  copies  the  argument 
list  hack:  to  the  user  area,  and  returns  in  the  usual  way. 
If  the  call  is  valid,  the  Gate_Keeper  calls  the 
appropriate  module  (e.g.,  Segment_Manager )  at  the 
requested  entry  point  into  the  module. 

When  the  module  has  completed  the  requested  task 
it  returns  to  the  Sate_Keeper .  The  return  message  is  then 
copied  to  the  user's  return  argument,  and  a  return  to  the 
user  ring  occurs.  All  entries  into  and  exits  from  the 
Kernel  are  through  the  Gate_Keeper. 

Parameter  passing  to  and  from  the  Kernel  is  by 
value  only.  Since  implementation  details  of  how  ?LZ 
modules  pass  parameters  are  unknown,  the  decision  on  the 
precise  mechanism  for  argument  passing  is  left  for  the 
implementor.  It  may  he  best  to  align  the  method  of 
parameter  passing  as  closely  as  possible  to  the  method 
used  by  the  PLZ/STS  language. 
4 .   Segment  Manager  Module 

The  Segment_Manager  is  responsible  for  managing 
the  segmented  physical  memory  and  uses  the 
Known_Segment_Table  (5ST)  as  its  primary  datatase.  In 
keeping   with   the   loop-free   structure   and   since   the 
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Function  Code 


Function 

Number   of 
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Para-1 
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Para-2 
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•  •  • 
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Segment 
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Swap_In 

S wap_0ut 

310CK 

WakeJJ? 

Figure  5.   Parameter  Table 
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Segment_Manager  is  the  only  module  at  level  3  of  the 
Kernel,  only  calls  external  to  the  Kernel  domain  may  be 
made  to  the  Segment_Manager .  There  are  six  entries  into 
the  Segment_Manager  in  this  implementation: 

1)  Create_Segment 

2)  Delete_Segment 

3)  Make_Known 

4)  Terminate 

5)  Swap_In 

6)  Swap_0ut 

a.   Known  Segment  Table 

The  data  structure  used  by  the  3egment_tfanager 
to  manage  segments  is  the  Known  Segment  Table  (EST).  The 
KST  is  a  "process  local"  data  structure  and  contains  an 
entry  for  each  segment  which  the  process  has  declared  an 
intention  to  use  (viz.,  "made-known").  The  segments  may  or 
may  not  be  located  in  main  memory.  If  a  sesment  has  an 
entry  in  the  KST,  then  the  segment  is  described  as  known 
to  the  process.  In  this  design  it  will  also  nave  an  entry 
in  the  Active  Segment  Table  (AST — a  Memory_^anager 
database  explained  later)  and  can  be  described  as  active. 
The  KST  (figure  5)  is  indexed  by  the  segment  numbers 
(Segment_#)  which  are  assigned  by  the  Segment_.v,anager .  Tne 
Segment_*  also  corresponds  to  the  MMU  descriptor  register 
for  the  segment.  The  ASTE_#  is  the  Active  Segment  Ta':lr 
entry  number  and  is  obtained  from  the  ^emo ry_Manager .  The 
ASTE_#    is    the    "handle"   which   is   passed   to 
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Memory_Manager  when  necessary  to  identify  a  particular 
active  segment.  The  Size  field  is  an  integer  which  is  the 
size  of  the  segnent  in  bytes  divided  by  256.  All  segments 
are  created  in  multiples  of  256  bytes  because  of  MMU 
constraints.  An  upper  bound  ( Max_Segment_S ize)  is  placed 
on  the  segment  Size  by  the  design  (explained  later).  A 
flag  known  as  In_Core  is  used  to  indicate  whether  the 
segment  is  in  main  memory  or  on  secondary  storage. 

The  last  field  in  the  KST  entry  is  the  access 
class  of  the  segment.  This  is  a  label  which  indicates  the 
security  classification  of  the  segment.  Interpretation  of 
the  Class  to  determine  an  access  mode  (read  or  read/write) 
is  performed  by  the  software  (by  a  call  to 
Non_Discretionary_Security )  on  first  reference;  thereafter 
the  access  mode  is  enforced  by  the  MMU. 

Figure  6  shows  both  the  logical  view  and  the 
PLZ  variable  declaration  for  the  KST.  Max_KST_Size  is 
hardware  dependent  and  is  equal  to  the  maximum  number  of 
segments  which  can  be  mapped  by  the  MMU.  To  access  an 
element  of  the  database  the  following  notation  is  used: 

KST  [Segment_#].  ASTE_# 
If  Segment_#  is  equal  to  103  then  the  above  statement  will 
reference   the   ASTH_*  field  of  the  KST  entry  fcr  segment 
number  103. 

b.   Creation  and  Deletion  of  Segments 

Create_Segment  and  Delete_Segment  are  two  of 
the  six  Supervisor  entries  into   the  Segment_Manager. 
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—  Segment_# 
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Mode 

In 
Core 
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Known  Segment  Table  Logical  View 
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KST_Sntry  Record  [ASTE_#  AST  Index 

Size  Integer 
Access_Mode  Integer 
In_Core  Byte 
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Internal    !  Internal  to  the  Sesmer  t_Manager  ! 
KST  Array  [MaT_KST_S ize  KST_Entry] 


Known  Segment  Table  Database  Definition 


Figure  6.   Known  Segment  Table 
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Create_Segment  (figure  7)  is  the  function  which  adds  a  new 
segment  to  the  Archival  Storage  System  after  validating 
the  parameters  which  are  passed.  The  creation  of  a  segment 
is  accomplished  by  requesting  the  Memory_Manager  process 
to  make  an  entry  in  the  Alias  Table  and  to  allocate 
storage  on  secondary  media. 

The  Alias  Table  is  a  database  which  is 
maintained  by  the  Memory_Manager .  It  is  a  result  of  the 
aliasing  scheme  used  by  the  kernel  to  prevent  passing 
systemwide  information  (such  as  the  unique  identification 
of  a  segment)  out  of  the  Kernel  [20].  The  alias  of  a 
segment  is  the  segment  number  of  a  "mentor"  segment  (a 
process  local  variable)  and  the  entry  number  in  the 
Alias_Table.  The  principal  implication  of  the  aliasing 
scheme  is  that  a  mentor  segment  must  be  known  before  a 
segment  can  be  created.  The  Alias  Table  will  be  further 
explained  in  a  succeeding  section. 

The  arguments  which  must  be  passed  to 
Create_Segment  are  the  Men tcr_Segment_- ,  the  desired 
2ntry_#  (in  the  Alias_Table )  ,  the  Class  of  the  segment  (a 
label),  and  the  desired  Size  of  the  segment.  The  KST  is 
searched  to  insure  that  the  Mentor  segment  is  known.  Next, 
Non_Discretionary_Secur ity  must  be  called  to  determine  if 
the  segment  is  compatible  [2].  (To  be  compatible,  a  mentor 
segment  classification  must  be  less  than  or  equal  to  the 
created  segment.)  The  compatibility  chec*  can  be  performed 
in   the  Segment  Manager  or  the  Memory  Manager.  In  addition 
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Create_Segment  Procedure  ( Mentor_Segment_#  Integer 

Entry_#  Integer 
Class  Longvord 
Size  Integer) 
Returns  (Success_Code  Integer) 

Entry 
Do 

If    KST[Mentor_Segment_#")  .ASTE_#   =   Null 
Then   Success_Code    :=   Mentor_Seg   Not   Found 

Exit 
Fi 
If  Non_Disc  Security(?rocess_Class , 

KST  [Mentor_Segment_#] .Class)    O   Equal 
Then   Success_Code    :=   Not_Alloved 

Exi  t 
Fi 
Compat_Check  :=  Non_Disc_Security( Class , 

KST[Mentor_Segment_#] .Class) 
If   Com?at_Check   =   Less_Than 
Orif   Compat_Check:  =   Not_Related 
Then    Success_Code    :=   Not_Compati hie 

Exit 
Fi 

If  Size  >  Max_Segment_Size 
Then  Success_Code  :=  Segment_Too  Large 

Exit 
Fi 
Signal    (Memory_Manager ,Create_Entry , 

KST    [Mentor_Segment_#]  .ASTE_#,  Entry_#, Class  ,S  ize  ) 
Success_Code    :=  Wait 
Od 

End   Create_Segment 


Figure  7.   Create_Segment  Procedure 
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to  the  compatibility  check:,  a  check  must  be  made  to 
determine  if  the  process  access  class  is  equal  to  the 
access  class  of  the  Alias_Table  since  adding  an  entry 
implies  write  permission  to  the  Alias_Table.  A  check  is 
then  made  on  the  Size  parameter  to  insure  that  it  is  in 
the  range  of  256  bytes  to  32K  bytes.  The  maximum  size  of  a 
segment  is  determined  by  the  size  of  the  design  of  the 
secondary  storage  page  table  and  the  hardware  constrains 
the  segment  to  multiples  of  256. 

If  an  error  is  discovered  luring  any  of  the 
preceding  checks,  then  an  appropriate  error  code  is 
returned  (e.g.,  Parent_Segment_Not_Found) .  If  tnere  are  no 
errors,  the  Segnent_Manager  Signals  the  Memory_v!anager 
with  a  request  to  make  an  entry  in  the  Alias_Table.  The 
Segment_Manager  must  Wait  for  a  success  code  from  tne 
Memory_Manager  since  the  Entry_#  can  only  be  checked  for  a 
duplication  by  the  Memory_Manager .  When  the  Memory_Manager 
Signals  the  Se<?ment_Manager  that  the  task  has  been 
completed,  the  Segment_Manager  returns  the  Success_Code  to 
the  process.  Note  that  the  segment  has  only  been  created 
and  if  the  Supervisor  now  wishes  to  reference  the  segment 
it  must  first  request  the  segment  be  entered  into  the  KST 
(Make_Known) . 

Delete_Segment   (figure   8)   accomplishes   the 
reverse   of   Create_Segment ,   that   is   the   removal  c*:    ?. 
directory   entry.    The    two    input    parameters 
Delete_Segment   are   Mentor_Segment_*   and  Intry_3.  Again, 
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Delete_Segment  Procedure  (Mentor_Segment_#  Integer 

Entry_#  Integer) 
Returns  (Success_Code  Integer) 

Entry- 
Do 

If  KST[Mentor_Segment_#] .ASTE_#  =  Null 
Then  Success_Code  :=  Mentor_Seg_Not_Found 

Exit 
Fi 
If   Non_Disc_Security(Process_Class , 

KST[Mentor_Segment_#] .Class )    =   Equal 
Then    Signal    (Memory  Manager .Delete   Entry, 

KST  [Mentor_3egment_#]7ASTZ_#,Entry_*) 
Success_Code  :=  Wait 
Else  Success_Code  :=  Not_Alloved 
Fi 
Od 

End   Delete_Segrrient 


Figure  8.   Delete_Segent  Procedure 
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the  mentor  segment  must  be  known  before  the 
Segment_Manager  can  honor  the  request.  Since  the  mentor 
segment  must  be  known,  compatibility  was  checked  when  the 
segment  was  created.  The  process  access  class  must  also  ^e 
equal  to  the  access  class  of  the  mentor  segment  since 
deleting  an  entry  Implies  write  permission.  When  all 
security  checks  have  been  made,  the  3egment_Manager 
Signals  the  Memory_Manager  to  delete  the  entry  from  the 
Alias_Table.  The  Segment_Manager  Waits  for  the 
Memory_Manage r  to  complete  the  task  and  it  returns  the 
Success_Code  from  the  Memory_Manager  to  the  Supervisor 
process.  The  Wait  is  necessary  because  an  error  occurs  if 
the  Mentor_Segment  is  not  empty  prior  to  the  deletion, 
c.   Managing  the  Segmented  Address  Space 

A  process  must  declare  an  intention  to  use  a 
segment  before  it  can  reference  the  segment.  This 
declaration  introduces  the  segment  into  the  address  space 
of  the  process.  The  way  the  Supervisor  declares  its 
intention  to  use  a  segment  is  to  ask  that  a  Segment_#  be 
assigned.  This  results  in  an  entry  in  the 
Known_Segment_Table .  Make_Enown  is  the  entry  point  into 
the  Segment_Manager  tc  accomplish  an  entry  in  the  SST. 

A  call  to  Make_Known  (figure  9)  requires  three 
parameters:   1)   Ment cr_Segment_#f   2)   3ntry_*,   and 
Access_Mode_Desi red .   Seg^ent_#   is   the   value   which  the 
Segment_Manager  returns  to  the  Supervisor  process   and   is 
the   index   to  the  KST  entry  and  to  the  segment  descriptor 
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Make  Known  Procedure 


( Mentor_Segment_#  Integer 

Entry_#""lnteger 

Access  Mode  Desired  Access  Mode) 


Returns  (Segment_#  Integer 

Access_Mode_Allowed  Access_Mode 
Success_Code  Integer) 


Local  Index  Integer 
ASTE_#  Word 
Class  Longvord 
Size  Integer 


Entry 
Get 


_Seg_#:    Do 

If   KST [Mentor_Segmen 
Then   Success_Code    := 
Exit    From  Get_S 
Else   Signal    (Memory_ 
KST    [Mentor_ 
ASTEJ*,    Class,   Siz 
If   Success   Code   = 
Then    Index~:=  0 
Search:   Do 

If 
The 


Od 


Fi 
Ind 
If 
The 
Fi 

Repe 
! Sea  re 


t_#]  .ASTE#  =  Null 
Mentor _Not_Known 

Manager ,  Activate, 
Segment_#]  .  ASTE_# ,Sntry_*) 
e,  Success_Code~:=  Wait 
Segment_Found 


KST  [Index] .ASTE_#  =  ASTE_# 
n  Segment_#  :=  Index 

Success_Code  :=  Already_Known 

Access  Mode_Allowed  := 

KST[Segment_*] .  Access_Mode 

Exit   From   Get_Seg_# 

ex   +=  1 

Index  >  Max_Number_Of_Segments 

n  Exit  From  Search 


at 
h! 


From  Search 


Figure  9.   Make_Known  Procedure 
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Index    :=   0 
Find_Entry: 


Orif 

Then 

Else 


Od 


Do 
If   KST    [Index]  .ASTE_#   =   Null 
Then    If   Non_Disc_Securi ty( Process_Ciass , 
Class)    =   Less_Than 
Non_Dlsc   Security(Process_Class , 

Class)    =   Not_?.elated 
Access_Mode_Allowed    :=  Null 
If   Non~Disc~Security(Process_Class, 

Class)    =  Equal 
Then   Access_Mode_Allowed    := 
Access_Mode_Desired 
Else    Access_Mode_Allowed    :=    Read 
Fi 
?i 

If   Access_Mode_Allowed   <>   Null 
Then   Segment_#    :=   Index 

KSTTSegment    #] .ASTE    #    :=   ASTE_# 
KST[Segment~#]  .Class    :=   Class 
EST[Segment_#] . Access_Mode    := 

Access   Mode_Allowed 
KST[Segment_#]  .Size    :=   Size 
EST[Segment_#] .In_Core    :=   No 
Success_Code    :=   Segment_Found 
Inner_TC(Add_Seg,Segment_* , 
Access_Mode_Al lowed ) 
Else   Segment~#    :=   Null 

Success_Code    :=   Not_Allowed 
Fi 

Exit    From  Find_Entry 
Fi 

Index   +=   1 

If  Index  >  Max_Number_Of_Segments 
Then  Segment_#  :=  No_Segments_Avail 

Exit  From  Get_Seg_# 
Fi 
Repeat  From  Find_Sntry 

Od  ~!Find_Entryl 

lGet_Seg_#l 


End   Make  Known 


Figure  9.  Make_Known  Procedure  (Continued) 
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in  the  MMU  hardware.  Different  processes  using  the  same 
segment  will  not  have  the  same  5egment_#  for  the  segment, 
since  each  process  has  its  own  KST.  Three  parameters  are 
returned  from  Make_Known:  1)  the  assigned  Segment_#,  2) 
the  Access_Mode_Allowed  which  may  be  less  than 
Access_Mode_Requested,  and  3)  a  Success_Code.  If  the 
Success_Code  indicates  an  error  the  first  two  parameters 
are  Null. 

Make_Known  first  Signals  the  Memory_Manager 
and  Waits  for  the  ASTE_#  of  the  segment.  If  more  than  two 
rings  were  implemented,  ring  brackets  would  also  be 
required  from  the  Memory_Manager  [10].  A  search  of  the  KST 
then  will  reveal  if  the  segment  is  already  known.  If  it  is 
known,  the  assigned  Segment_#  the  Access_Mode_Allowed 
(unchanged),  and  a  Success_Code  of  Already_Known  are 
returned.  Access_Mode_Allowed  cannot  be  changed  for 
segments  in  the  address  space.  If  there  is  no  entry  in  the 
KST,  an  entry  is  made  by  filling  in  the  columns  of  the  KST 
at  the  first  available  Segment_~. 
Non_Discretionary_Security  is  called  to  interpret  the 
security  labels  of  the  subject  and  the  object.  Access  to 
the  segment  is  then  granted  with  the  access  allowed  eaual 
to  the  less  privileged  of  Access_Mode_Desired  or 
Max_Access_Allowable .  If  write  access  is  requested  but 
security  allows  only  read,  read  is  the  access  granted.  A 
call  must  also  be  made  to  the  Inner_Traf f ic_Controlle r 
add  the  segment  descriptor  to  the  hardware  descriptor  list 
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(MMU)  and  the  software  image  of  the  descriptor  list. 

If  the  maximum  number  of  segments  is  exceeded 
Make_Known  will  return  No_Segmen t_Available.  The  process 
then  has  the  option  of  terminating  any  other  segment  to 
make  room  for  the  required  segment.  (Note  that  the  maximum 
number  of  segments  allowed  by  the  hardware  could  be 
exceeded  without  using  all  of  the  linear  "virtual  core" 
allocation  or  conversely.)  Terminate  is  the  entry  point  in 
the  Segment_Manager  to  remove  a  segment  from  the  KST. 

Terminate  (figure  10)  is  responsible  for 
removing  the  segment  frcm  the  address  space  and  reflects 
this  by  removing  the  entry  from  the  K5T .  The  only  argument 
which  must  be  passed  is  the  Segment_*  to  be  terminated. 
The  return  argument  is  a  Success_Code .  There  are  four 
errors  which  can  be  found  by  the  Segment_Manager :  1)  a 
segment  which  is  not  known,  2)  attempting  to  terminate  a 
segment  still  loaded  in  the  process  virtual  core,  3) 
attempting  to  terminate  a  Kernel  segment,  and  4)  passing 
an  invalid  Segment_*  (too  large).  The  Menory_Manager  is 
Signaled  to  Deactivate  the  segment  (remove  the  AST  entry) 
and  a  Wait  occurs  until  the  Deactivate  is  completed.  Note 
that  the  Wait  is  to  insure  that  a  race  condition  between 
the  Memory_Manager  and  Supervisor  process  [11]  does  not 
occur.  The  KST  entry  is  deleted  by  setting  the  AST_*  of 
the  KST  entry  to  null,  calling  the 
Inner_Traff ic_Controller  to  delete  the  segment  from  the 
descriptor  segment  and  returning. 
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Terminate  Procedure  (Segment_#  Integer) 
Returns  (Success_Code  Integer) 

Entry 
Do 

If   KST[Segment_#] ,ASTE_#  =   Null 

Then  Success  Code  :=  Segment  Mot  Known 

Siit 
Pi 

If   KST[Segment_#] .In_Core   =   Yes 
Then  Success_Code    :=  Segment_In   Core 

Exit 
Fi 

If  Segment_#  <=  Number_Iernel_Segments 
Then  Success  Code  :=  Kernel_Segment 

Exit 
Fi 

If  Segment_#  >  Max_Segment_# 
Then  Success  Code  7=  Invalid_Segment_# 

Exit 
Fi 

Signal(Memory_Manager,Deactivate,KST  [Segment _#]  .ASTE_#) 
Success_Code    :=  Wait 
KST[Segment_#] .ASTE_#    :=  Null 
Inner  TC( Delete  S eg  ,Segment_#) 
Od 

End   Terminate 


Figure   10.      Terminate   Procedure 
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d.   Moving  Segments  into  Memory 

Swap_In  (figure  11)  and  Swap_Gut  (figure  12) 
are  the  two  procedures  in  the  Segment_Manager  which  move 
segments  between  main  memory  and  secondary  storage. 
(Secondary  storage  is  used  as  a  generic  term  in  this 
thesis  to  indicate  all  memory  of  a  computer  system  other 
than  main  or  core  memory.  It  includes  "tertiary"  or  lower 
order  memory.)  To  move  a  segment  from  secondary  storage  to 
main  memory,  a  process  must  call  5wap_In  with  tne 
Segment_#  and  3ase_Address  as  arguments.  3ase_Address  is 
the  location  in  the  linear  virtual  core  of  the  process 
where  the  segment  is  to  begin.  This  is  a  virtual  core 
address  and  does  not  correspond  to  a  real  address  in 
memory;  in  fact,  memory  cannot  be  addressed  at  all  except 
by  addressing  a  segment.  The  Segment_Manager  indexes  to 
the  segment  in  the  KST  to  retrieve  the  necessary 
attributes  for  moving  the  segment.  If  the  segment  is  not 
found,  Segment_Nct_?ound  is  returned.  After  obtaining  the 
attributes  of  the  segment,  the  Segment_Manager  Signals  the 
Memory_Manager  to  do  the  transfer.  A  Wait  is  then  executed 
until  the  Memory_Manager  can  send  the  Absolute_Address  In 
real  memory  to  the  Segment ^Manager .  This  information  is 
passed  to  the  Inner_Traf f ic_Controller  to  update  the 
absolute  address  in  the  hardware  and  software  descriptor 
lists.  This  procedure  only  works  because  of  the  design 
choice  not  to  unload  a  process  from  a  virtual  processor. 
If  processes  are  unloaded  the  Memcry_Manager  would  have  to 
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Swap_In   Procedure    (Segment_#    Integer 

3ase_Address  Word) 
Returns  ( Success_Code  Integer) 

Entry 

If   XST[Segment_#] .ASTE_#  =   Null 
Then   Success_Code    :=   Seg_Not_Found 

Exit 
Fi 
Signal    ( Memory_Manager , In, Segment    #, 

KST    [Segmental . ASTE_#,Base_Address , 
KST [Segment_#] >Access_Mode )" 
Absolute_Address ,Success_Code    :=  Wait 
If   Success_Code   =   Swapped_In 

Then    Inner   TC    (Load, Segment   # ,Absolute_Address , 
KST  [Segmental. Size) 
KST[Segment    #].In_Core    :=   Tes 
Fi 
End   Swap_In 


Figure  11.   Swap_In  Procedure 
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Swap_Out  Procedure  (Segment_#  Integer) 
Returns  (Succe ss_Code  Integer) 


Entry 

If  KST [Segment _#] .ASTE  #  =  Null 
Then  Success_Code  :=  Seg_Not_Found 

Exit 
Fi 

Written  :=  Inner_TC  (Unload ,Segment_# ) 

Signal  ( Memo ry_Manager, Out ,KST  [Segment _*1 .ASTE_#, Wri tten) 
KST[Segment_#] .In_Core  :=  No 
Success  Code  :=  Swapped_Out 


End  Swap_0ut 


Figure  12.   Swap_0ut  Procedure 
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call  the  Inner_Traff ic_Controller.  The  parameter  returned 
to  the  process  indicates  if  the  segment  swap-in  was 
successful. 

The  move  in  the  other  direction — mam  memory 
to  secondary  storage — is  performed  by  Swap_0ut.  The  only 
input  argument  is  the  Segment_#  and  Success_Code  is  the 
only  return  argument.  After  validation  of  the  5egment_#, 
the  Segment_Manager  calls  the  Inner_Traf f i c_Controller  to 
obtain  the  status  of  the  hardware  changed  bit.  This  is  in 
turn  passed  by  Signal  to  the  Memory_Manager  to  make  the 
change.  Success_Code  is  set  to  Swap_0ut  and  the 
Segment_Manager  returns.  If  more  than  one  processor  is 
used  in  the  system,  race  conditions  should  be  investigated 
in  this  procedure  of  allowing  the  Segment_Manager  rather 
than  the  t*emory_Manager  to  call  the 
Inner_Traff ic_C on t roller. 

To  this  point  the  usual  order  for  invoking  the 
Segment_Manager  functions  has  not  been  specified.  There  is 
a  usual  sequence  of  events.  In  order:  Create_Segment  to 
make  an  Alias_Table  entry,  i".ake_£nown  to  introduce  the 
segment  into  the  address  space,  and  Swap_In  to  neve  the 
segment  into  the  process's  virtual  core  are  the  steps 
necessary  before  a  process  can  make  a  reference  to  a 
segment.  Conversely,  Swap_0ut,  Terminate,  and 
Delete_Segment  is  the  order  to  move  a  segment  from  mair. 
memory  to  secondary  storage,  remove  the  entry  from  the  KSI 
and  descriptor  from  the  l"^U,  and  remove  the   segment   from 
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the  address  space.  If  the  functions  are  called  in  any- 
other  order,  the  usual  result  is  an  error  condition  and  no 
action  is  taken.  No  'harm'  results  from  calls  made  out  of 
sequence . 

5 .   Traffic  Controller  Module 

The  Traf f ic_Controller  is  responsible  for 
multiplexing  processes  onto  virtual  processors.  A  virtual 
processor  is  an  abstraction  which  describes  a  logical 
processor.  There  are  multiple  virtual  processors  which 
exist  on  a  single  physical  processor.  The 
Traf f ic_Controller  is  also  the  Kernel  module  which 
supports  the  interprocess  communication  primitives,  Block 
and  Wake_Up.  In  the  Archival  Storage  System,  31ocx  and 
Wake_Up  are  the  last  two  of  the  six  user  entries  into  the 
Kernel.  There  are  four  other  procedures  in  the 
Traf f ic_Controller  which  implement  the  scheduling 
algorithm  and  provide  message  queue  services  for  Block  and 
WakeJJp. 

a.   Active  Process  Table 

The  database  of  the  Traf f ic_Controller  is  the 
Active  Process  Table  (APT)  (figure  13).  This  is  a 
fixed-size  table  in  the  Kernel  because  of  the  decision  not 
to  create  or  destroy  processes.  When  the  Archival  Storage 
System  goes  through  system  generation,  each  process  will 
be  created  and  an  entry  made  in  the  APT.  The  process  will 
then  be  active  for  the  life  of  the  system.  Sach  active 
orocess  will  have  a  uniaue  identifier   (Process  ID)   which 
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rProcess  ID 


Priority 

State 

Wake  Up 
Waiting 
Switch 

Priori  ty 

Req  'd 

Virt 
Processor 

>          i 

...  _  J 

Figure  13.   Active  Process  Table 
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is  also  the  index  to  the  APT.  Note  that  if  processes  were 
created  and  destroyed,  then  allowing  Process_IDs  to  leave 
the  Kernel  could  create  a  communication  path.  In  that  case 
the  Process_ID  should  be  " vir tualized" .  The  State  field  of 
the  APT  indicates  whether  a  process  is  blocked,  ready,  or 
running. 

An  explanation  of  the  interprocess 
communication  primitives  is  necessary  here.  Block  and 
Wake_Up  [19]  are  the  interprocess  communication  primitives 
used  by  cooperating  processes  in  the  Supervisor  domain. 
Invocation  of  the  primitives  is  actually  a  call  to  the 
Traff ic_Controller  and  causes  the  Traf f ic_Controller  to 
execute  the  scheduling  algorithm.  A  process  calls  Wake_*Jp 
when  it  has  a  message  or  task  for  another  process.  Wake_Up 
will  set  the  state  of  a  blocked  process  to  ready.  If  the 
process  is  ready  or  running  it  will  have  no  effect  on  the 
status  of  the  process.  When  a  process  cannot  continue 
execution  until  a  reply  to  a  Wake_Up  is  received,  the 
process  must  block  itself.  31ock  will  set  the  process 
status  to  blocked. 

Within  the  Kernel  Signal  and  Wait  are  the 
primitives  used  for  communication.  They  function  in  the 
same  manner  as  Block  and  Wake_up,  but  are  calls  to  the 
Inner_Traf f ic_Controller  instead  of  the 
Traff ic_Controller .  Signal  and  Wait  are  bounded  in  time 
which  indicates  that  they  are  guaranteed  to  return.  Block 
and   Wake_Up   are   not  bounded  since  no  claims  can  be  male 
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about  correctness  of  calls  from  outside  the  Kernel.  It  is 
possible  for  a  user  process  to  call  31oc*  erroneously  and 
never  be  heard  from  again. 

The  Wake-Up  Waiting  Switch  is  Saltzer's  [19] 
mechanism  for  synchronization  of  interprocess 
communication  primitives.  Without  the  switch  a  race 
condition  can  occur.  For  example,  the  following  sequence 
of  events  could  happen  because  processes  can  run 
simul taneously : 

1)  Process  A  Looks  in  its  work  aueue 
and  finds  it  empty. 

2)  Process  3  puts  a  task  in  A's  work  queue. 

3)  B  wakes  up  A. 

4)  A  blocks  itself. 

At  step  3,  A  was  running,  so  the  wake-up  sent  by  3  was 
ignored.  When  A  called  block,  a  task  is  in  the  work  queue, 
but  A  missed  the  wake-up  signal,  so  the  task  remains 
uncompleted.  In  particular,  if  A  was  expecting  some  event 
necessary  for  A  to  continue,  A  may  never  wake-up. 

The  Wake-Up  Waiting  Switch  prevents  the 
occurrence  of  such  a  situation  by  requiring  the  following 
sequence  of  actions: 

Process  B: 

1)  Process  3  puts  task  in  Process  A's 
work  queue. 

2)  Wake-up  A  and  turn  wake-up  waiting 
switch  on. 


ee 


Process  A: 

1)  Reset  the  wake-up  waiting  switch  to  off. 

2)  Look  in  the  work  queue  and  find  it  empty 

3)  Call  Block,  which  returns  if  wake-up 
waiting  switch  is  on. 

Now,  the  above  sequences  can  occur  in  an/  time 
relationship  and  the  wake-up  signal  will  have  the  desired 
effect . 

The  Traffic_Controller  uses  the  priority  field 
for  determining  what  process  to  schedule  to  run  on  the 
virtual  processor.  The  Reauired_7irtual_?rocessor  field  is 
used  to  bind  a  loaded  process  to  a  specific  virtual 
processor.  Only  two  processes  run  on  a  virtual 
processor — the  loaded  process  and  the  "idle"  process.  This 
is  a  direct  result  of  the  simplifying  design  choice  (to 
have  all  processes  loaded)  made  for  the  Archival  Storage 
System.  In  general,  processes  must  he  loaded  and  unloaded. 
The  Idle  process  is  put  into  the  running  state  whenever 
the  loaded  process  blocks  itself. 

b.   Interprocess  Communication  Primitives 

Eecause  the  Archival  Storage  System  does  not 
allow  creation  or  destruction  of  processes  except  at 
system  generation,  the  only  external  entry  points  into  the 
Traf f ic_Controller  are  Block  and  Wake_Up.  As  previously 
explained,  Block  and  Wake_Up  are  the  primitives  used  ty 
Supervisor  processes  for  interprocess  communication. 

Block  (figure  li)    is   called  when  a   process 
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Block:  Procedure 

Returns  (Process_ID  Integer 

Message  Message_Type ) 

Entry 

If   APT    [Process_ID] .Wakeup_Wai ting   Switch   =  On 
Then   APT    [Process_IDl  .Wakeup_Wai ting   Switch    :=  Off 
Else   APT    [?rocess_IDJ  .State    :=   Blocked 

Sched_Ready  Process 
PI 
?rocess_IL , Message    :=   Get_First_Message( Message_Oueue ) 

End   31ock 


Figure  14.  Block  Procedure 
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cannot  continue  until  the  occurrence  of  some  other  event. 
After  going  through  the  Sate_Keeper,  the  call  enters  the 
Traffic_Controller.  The  Wake_Up_Wait ing_Swi tch  is 
immediately  checked.  If  the  switch  is  on,  the  switch  is 
reset  to  off,  and  the  first  message  in  the  Message_Cueue 
for  the  process  is  retrieved.  The  Traf f ic_Controller  then 
returns  through  the  Gate_Keeper . 

If  the  Wake_0*p_W'aiting_Switch  was  off  then  the 
state  of  the  process  is  set  to  Blocked. 
Sched_Ready_Process  is  called  to  schedule  the  highest 
priority  ready  process  on  the  virtual  processor.  In  the 
Archival  Storage  System  this  is  a  trivial  task,  because 
the  only  other  process  which  is  loaded  on  the  virtual 
processor  is  the  idle  process.  The  idle  process  can  never 
block  itself,  so  it  must  always  be  either  running  or 
ready.  In  fact  the  idle  process  will  only  consist  cf  a 
halt  instruction. 

The  Traf f ic_Controller  could  have  been 
collapsed  into  the  I nner_Traf f ic_C ontroller  for  this 
design,  but  preservation  of  generality  was  a  design  goal. 
Later  extensions  will  be  easier  to  implement  since  the 
basic  structure  of  the  Traf fic_Controller  is  present. 

The  counterpart  of  Block  is  Wake_Up.  #ake_'J? 
(figure  15)  is  used  by  processes  in  the  Supervisor  domain 
to  pass  messages  to  other  processes  in  the  Supervisor 
domain.  Upon  entry  into  Wake_Up,  the  message  is  placed  in 
the   Message   Queue   of   the   awakened   process.   The 
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Wake_Up  Procedure  (Wakeup_Process_ID  Integer 

Message   Message_Type) 
Returns    (Success_Code    Integer) 


Entry 
Do 
Sue 
If 
Ori 
The 
lis 


cess_Code  :=  Inser t_Message ( Wakeup_Process_ID  Message) 

Success_Code  =  Queue_Overf low 

f  Success_Code  =  Not_Alloved 

n  Exit 

e    APT    [Wakeup_?rocess_ID]  .Wakeup_Waiting_Switch    :=   On 

If   APT    [tfakeup_Process_II3] .State    =  Blocked 

Then    APT    [Wakeup_Process_ID] .State    :=   Ready 
Enter  Ready_Oueue    (Wakeup   ?rocess_ID) 

Pi 

APT    [Process_ID]  .State    =   Ready 

Enter_Ready_Queue(Process_ID ) 

Sched_Ready_Process 


Fi 
Od 
End  Wake_(Jp 


Figure  15.  Wake-up  Procedure 
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Wake_Up_Waiting_Switch  of  the  process  to  be  awakened  is 
then  set  to  On.  Then  if  the  process  state  is  blocked  it  is 
put  into  the  Ready_Queue  and  the  State  is  set  to  ready. 
Regardless  of  the  state  of  the  awakened  process,  the 
waking  process  then  puts  itself  into  a  Read/  State  and 
Enters  the  Ready_Queue  itself.  This  is  necessary  because 
the  process  to  be  awakened  may  ha7e  a  higher  priority  than 
the  waking  process.  Every  time  either  Elock  or  Vake_Up  is 
called  the  scheduling  algorithm  is  executed 
(Sched_Ready_Process ) . 

c.   Process  Scheduling  Algorithm 

Enter_P.eady_Queue  (figure  16)  and 
Sched_Ready_?rocess  (figure  17)  are  two  internal  functions 
of  the  Traf f ic_Controller .  En ter_Ready_Queue  is  used  for 
placing  a  ready  process  into  a  first-in,  first-out  queue 
which  is  organized  by  priority  (figure  16).  The 
Ready_Queue  is  designed  as  a  two-dimensional  array  indexed 
by  Priority  and  a  top  and  bottom  pointer.  The  algorithms 
for  all  queue  operations  are  taken  from  Knuth  [21].  When  a 
Process_ID  is  to  be  added  to  the  queue  the  bottom  pointer 
for  the  appropriate  priority  queue  is  incremented  by  one. 
If  the  bottom  pointer  is  at  the  bottom  of  the  linear  array 
which  implements  the  queue  then  it  is  set  to  the  first 
location  of  the  array,  thus  wrapping  around.  The  physical 
length  of  each  queue  column  is  equal  to  the  total  number 
of  processes  which  can  be  entered  into  that  aueue  at  any 
point  in  time  so   that   the   queue   cannot   overflow. 
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Enter_Ready_Queue  Procedure  (Process_ID  Integer) 

Entry 

If   Ready_Queue_2ottom    [APT    [Process    ID] .Priority]    = 

Ma x_Queue_ Length 
Then  Ready_Queue_Bott om    [APT    [Process_ID] .Priority]     :=    0 
Else   Ready_Queue~Bottom    [APT    [Process_ID] .Priori ty]    +=    1 
Fi 

Peady_Queue  [APT    [Process_ID]  .Priori  ty,    Ready_Queue_Bot  torn] 

:=  Process_ID 

End   Enter_Ready_Queue 


Figure  16.   Enter_Ready_Queue  Procedure 
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Sched  Ready  Process  Procedure 


Entry 
Prio 
Scan 
If 


Th 


rity  := 
:  Do 
Ready_ 
Ready_ 
en  Prio 
If  P 
Then 
Else 
Fi 
Else  If  8 
Then 
Else 
Fi 
Run:  If 

Th 

El 

Fi 


Max_Priority 

Queue_Top    [Priority]    = 
Queue~Bottom    [Priority] 
rity  -=  1 
riority   <   Min_Priority 

Exit   From   Scan 

Repeat    From   Scan 

eady_Queue_Top [Priority]    =  Max_Queue_Iength 
Ready_Queue_Top [Priority]    :=    0 
Ready_Queue_Top [Priority]    +=   1 

APT[Ready_Process_ID]  .Reqd_7irt_?rocessor 

=   Processor   ID 
en   APT    [Ready_Process_ID] .State    :=   Running 

Inner_TC    ( Svap_MMU, Ready_Process_ID) 
se  Get_Next_Process(Ready_Queue ) 

Repeat   From   Run 


Fi 


Od 


End  Sched_Ready_Process 


Figure  17.   Sched_Ready_Process  Procedure 
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Figure  18.   Ready  Queue 
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Process_ID  is  placed  into  the  array  at  the  location 
pointed  to  by  the  bottom  pointer.  The  queue  is  always 
entered  at  the  logical  bottom  and  removal  takes  place  from 
the  logical  top. 

The  procedure  which  removes  the  processes  from 
the  top  of  the  queue  is  5ched_Ready_Process .  The  function 
of  Sched_Ready_Process  is  to  "pass"  (as  a  baton  in  a  relay 
race)  the  current  virtual  processor  to  the  highest 
priority,  ready  process  which  can  run  on  this  specific 
virtual  processor.  Starting  with  the  P.ax_?riority  queue, 
each  queue  is  scanned  until  the  first  ready  process  that 
can  run  on  the  virtual  processor  currently  executing  in 
the  Traf fic_Controller  is  encountered.  Each  aueue  is 
tested  in  turn  to  determine  if  it  is  empty.  If  the  queue 
is  empty,  then  the  next  lower  priority  queue  is  scanned. 
The  existence  of  an  Idle  process  for  each  virtual 
processor  guarantees  that  a  ready  process  is  always  found, 
so  the  Traf f ic_Controller  cannot  exit  without  scheduling  a 
process.  When  a  ready  process  is  found,  then  the  process 
State  is  set  to  running  (scheduled)  and  the 
Inner_Traff ic_Controller  is  called  to  SwapJIMU.  This 
generally  will  load  the  process  descriptor  segments  into 
the  Vir tual_?rocessor_MMU,  but  in  the  design  of  the 
Archival  Storage  System  the  MMU  of  the  Idle  process  is 
identical  to  the  MMU  of  the  loaded  process, 
d.   Message  Cueue  Operators 

The    Message_Gueue     (figure    19)    is    a 
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Figure  19.   Message  Queue  And  Pointers 
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two-dimensional  array  of  message  "frames".  It  is  indexed 
in  one  dimension  by  the  Process_ID  and  in  the  other 
dimension  hy  a  top  and  bottom  pointer.  Insert_Message 
(figure  20)  is  the  primitive  used  "by  W'a^e_Up  to  put  a 
message  into  another  process'  message  queue.  The  design 
only  allows  communication  between  processes  of  equal 
security  class  since  a  Success_Code  is  returned  to  the 
waking  process.  Get_?irs t_Message  (figure  21)  is  the 
primitive  used  by  Block  to  retrieve  messages  from  the 
message  queue.  If  the  queue  is  empty,  the  message 
"Queue_Empty"  is  returned. 

6 .   Non-Discretionary  Security  Module 

The  key  to  implementing  a  particular 
non-discretionary  security  policy  is  in  one  module.  By 
representing  the  policy  as  a  partially  ordered  lattice,  an 
interpretation  algorithm  can  be  written  to  ma.^e  a 
comparison  between  two  labels  and  return  a  relationship. 
The  relationship  can  be  equal,  less  than,  greater  than,  or 
not  related. 

The  Non_Discretionary_Securi ty  Module  shown  in 
figure  22  will  determine  the  relationship  of  three 
categories  of  classification  (Secret,  Confidential, 
Unclassified).  As  shown  there  are  no  checks  for 
compartments  (e.g.,  crypto,  nuclear,  etc.).  If  a  complete 
DOD  security  policy  interpretation  is  desired,  the  module 
can  be  expanded.  Since  some  DOD  specifications  require 
provisions  for  eight  categories  and  sixteen  compartments, 
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Insert_Message  Procedure  (Message_Queue_ID  Integer 

Message  Message_Type ) 
Returns  (Success_Code  Integer) 


Entry 

If  Non_Disc_Securi ty 

APT[Message 
Then 

If  Message_Queue_Bott 

=  Max 

Then  If  Message_Queue 

Then  SucceIs_Cod 

Else  Message_Que 

Message_Que 

Message  Que 


Success  Cod 


ri 


Else  If  Message_Queue 

=  Mess 

Then  Success_Cod 

Else  Message_Que 

Message_Que 

Message_Que 


Success    Cod 


(APT[Process_ID]  .Class, 
_Queue_ID] .Class)    =   Equal 

om  [Message_Queue_ID] 

_Queue_Length 

"Top  [Missage_Queue_ID]    =   0 

e    :=   Queue_Overflow 

ue   Bottom  [Message   Oueue_ID]     :=   d 

ue  [Message_Queue_Id  t 

ue_Bottom  [Message_Queue_IDl ] 

:=  Message , Process_ID 
e    :=   Inserted 

_Bottom[Messagre_Queue_ID]    +   1 
age_Queue_Top lMessage_Queue_ID] 
e    :=   Queue_Overf low 
ue   Bottom  [Message_Queue_ID]    +=   1 
uelMessage_Queue_ID , 
ue_Bottom  [Message_Oueue_ID] ] 

:=  Message, Process_ID 
e  :=  Inserted 


Pi 
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Else  Success_Code  :=  Not_Alloved 
Fi 
End  Insert_Message 


Figure  20.   Insert_Message  Procedure 
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Get_First_Message  Procedure  (Message_Queue_II5  Integer) 

Returns  (First_Message  Message_Type ) 


Entry 
If 

The 

Els 


Pi 


Message_Cueue_Top[tfessage_Queue_ID]  = 

Message_Queue_Bottom [Message_Queue_ID] 
n  First_Message  :=  Queue_Empty 
e  If  Message_Queue_Top [Message_Queue_ID]  = 
Max_Queue_Length 
Tnen  Message_Queue_Top [Message_Oueue_ID]  :=  0 
Else  Message_Queue_Top [Message~Queue  ID]  +=  1 
Fi 

First_Message  :=  Message_Queue [Message_Queue_IDf 
Message_Cueue_Top [Message_Queue_ID] ] 


End  First_Message 


Figure  21.   Get_First_Message  Procedure 
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Non_Disc_Security  Procedure  (Class_l  Longvord 

Class_2   Longword) 
Returns    (Relationship    Integer 


Entry 
If  C 
Ca 


lass_l 

se  Unclassified  Then 

If  Class_2 

Case  Unc 

Case  Con 


Ca 


Ca 


Els 
Fi 

se  Co 
If  CI 
Cas 
Cas 
Cas 
Els 
Pi 

se  Se 

If  CI 

Cas 


lassified  Then  Relationship  :=  Equal 
f idential ,Secret  Then  Relationship 
:=  Less_Than 
e  Relationship  :=  Not  Related 


nfidential  Then 
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e  Unc 

e  Con 

e  Sec 

e  Rel 


lassified  Then  Relationship  :=  Great erJTban 

fidential  Then  Relationship  :=  Equal 
ret  Then  Relationship  :=  Less_Than 
ationship  :=  Not_Related 


cret  Then 
ass_2 
e  Unc 


Case 

Else 


Sec 
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lassif iedtConf idential  Then 

Relationship  :=  G-reater_Than 
ret  Then  Relationship  :=  Equal 
ationship  :=  N'ot_Related 


El 


Pi 

se 


Relationship  :=  Not_Related 


11 


End  Non_Eisc_Security 


Figure  22.  Non_Disc_Securi ty  Procedure 
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a  longword  was  chosen  as  the  data  type  for  representing 
the  labels.  The  32  hits  0f  a  longword  are  more  than 
sufficient  to  represent  all  possible  combinations  of 
categories  and  compartments. 

Similarly,  Privacy  Act  requirements  are  easily 
implemented  in  Non_Discretionary_5ecuri ty  since  they  can 
be  represented  by  a  lattice  structure.  Most  other 
practical  non-discretionary  security  policies  can  be 
implemented  as  well. 

7.   Inner  Traffic  Controller  Module 

The  Inner_Traf f ic_Controller  provides  the 
multiplexing  of  virtual  processors  to  the  real  processor 
of  the  system,  ^ach  loaded  process  will  be  allocated  to  a 
virtual  processor,  implying  that  there  is  a  many  to  one 
correspondence.  In  order  to  manage  these  virtual 
processors,  the  Inner_Traf f ic_Controller  has  direct  access 
to  the  machine  hardware.  The  Memory  Management  Unit  and 
processor  state  are  loaded  and  unloaded  by  the 
Inner_Traff ic_Controller,  thus  accomplishing  the 
multiplexing  to  the  physical  processor. 

In  addition  to  managing  the  virtual 
processors,  the  Inner_Traf f ic_Controller  furnishes 
inter-process  services.  Signal  and  Wait  are  used  by 
processes  in  the  Kernel  ring  to  communicate  with  other 
Kernel  rin^  processes  and  are  primitives  of  the 
Inner_Traff ic_Cont roller . 

The   main   database   used    to   handle    the 
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Inner_Traff ic_Controller  functions  is  the 
Virtual_Processor_Table .  Additionally,  a  software  image  of 
each  MMU  is  maintained  for  every  loaded  process. 

a.  Virtual   Processor   Table 

The  Virtual_Processor_Table  (figure  23)  is 
indexed  by  the  Virtual_Processo r-ID.  Each  virtual 
processor  can  be  in  one  of  three  states:  1)  Running,  2) 
Ready,  or  3)  Waiting.  These  three  states  are  analogous  to 
the  state  of  a  process  and  are  used  for  processor 
scheduling  in  the  same  manner  as  the  Traf f ic_Gontroller 
used  the  state  of  a  process  for  scheduling  processes. 
After  the  State  field  is  the  Signal_Pending_S vitcn  which 
functions  precisely  as  the  Wake_Up_Wai ting_Swi tch  for 
preventing  a  race  condition  from  occurring  witn  the 
interprocess  communication  primitives.  Priority  is  the 
next  field  which  is  also  analogous  to  the  APT  priority. 

Loc_Processor_State  is  a  pointer  to  the  area 
in  memory  where  the  MMU  software  image  is  maintained  as 
well  as  the  "save  bloc*"  for  the  machine  state  of  the 
virtual  processor  when  it  is  ready  or  waiting.  Figure  24 
is  an  example  of  the  format  of  the  MMU  image. 

b.  Kernel  Interprocess  Communication  Primitives 
Signal  and  Wait  function  in  the  same  manner  as 

31ocic  and  Wa'<ce-Up.  The  chief  distinction  between  the  pairs 
is  the  degree  of  trust  placed  on  the  correctness  of  use. 
Since  Signal  and  Wait  are  Kernel  primitives  which  are  used 
only  by  process  operating  in  the  Kernel  domain,  the   calls 
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can  be  guaranteed  to  return.  The  same  trust  cannot  be 
placed  on  the  calls  to  Block:  and  Wake_Up  by  processes  in 
the  Supervisor  ring.  The  loop  free  structure  implies  that 
the  Kernel  neither  knows  nor  cares  what  happens  in  the 
outer  domain  for  domains,  if  present).  Yet,  the  Kernel 
must  not  allow  the  security  state  of  the  machine  to  change 
except  in  accordance  with  the  rules  of  the  mathematical 
model.  31ock  is  restricted  to  communication  among 
processes  at  the  same  level.  The  Kernel  must  call  upon 
processes  operating  at  different  security  levels  to 
accomplish  its  task  and  thus  needs  a  different  primitive 
since  systemwide  information  is  being  passed. 

With  one  exception,  Signal  figure  25)  and 
Wait  (figure  26)  function  in  the  same  manner  as  Wake_Up 
and  Block  do  in  the  Traf f ic_Controller .  Since  the  data 
structures  in  the  Inner_Traf f ic_Controller  function  with 
virtual  processors,  the  S ignaled_?rocess_ir  or  ?rocess_IT 
(input  parameters)  must  be  translated  into  a 
Signa  led_?rocesscr_irJ  or  Processor_ID .  A  one-dimensional 
table  is  maintained  for  this  purpose.  Because  the 
Inner_Traf f ic_Controller  must  complete  its  task  before  it 
returns  to  the  calling  procedure  and  is  synchronous  to  tie 
progress  of  the  process,  the  table  translation  of  process 
to  virtual  processor  works.  The  Idle  processes  will  never 
try  to  Signal  or  Wait  and  will  never  cause  the  scheduling 
algorithm  to  be  executed. 

It   is   oossible   for   the   Idle  process  to  be 
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Signal  Procedure  ( Signaled_Processor_ID  Integer 

Signal_Message  Message_Type ) 
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Figure  25.   Signal  Procedure 
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Wait  Procedure 

Returns  (Process_ID  Integer 

Signal_Message   Message_Type ) 
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Figure   26.      Wait    Procedure 
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scheduled  on  each  virtual  processor  in  the  storage  system. 
When  that  occurs  the  real  processor  will  cone  to  a 
standstill,  executing  a  Halt  instruction.  At  first  glance 
this  would  seem  to  be  an  error  condition,  but  in  reality 
it  is  not.  Since  the  Archival  System  is  driven  'oy  external 
events  this  may  at  times  be  a  normal  state.  When  a  request 
is  made  from  a  Eost,  the  interrupt  handler  (an  I/C_m*anager 
entry)  will  Signal  (via  the  Inner_Traffic_Cont roller )  the 
appropriate  process  and  cause  the  scneduling  algorithm  to 
be  executed. 

c.   Service  Functions 

All  of  the  functions  of  the 
Inner_Traff ic_Controller  are  called  from  the  Kernel  ring. 
Add_Seg,  Delete_Seg,  Load,  and  Unload  are  service  calls  to 
support  the  Segment_Manager .  These  are  hardware  dependent 
functions  and  the  details  of  their  design  will  be 
influenced  by  the  specific  characteristics  of  the  MMO  and 
CPU  hardware.  Add_Seg  makes  an  entry  into  an  PMJ  hardware 
descriptor  and  also  the  MMU  software  image.  This  call  is 
made  from  Make_^nown  and  will  only  set  up  the  descriptor. 
Since  the  segment  has  not  been  Swapped_Ir.  at  this  point, 
the  address  fields  of  the  descriptor  will  be  null  and  the 
attribute  field  of  the  descriptor  will  be  set  tc  inhibit 
the  CPU  from  making  access. 

Delete_Seg  is  called  from  terminate  and  is 
required  to  remove  an  entry  from  the  MMU  and  the  software 
image.  Load  will   place   the  absolute   location   af   the 
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segment  base  address  into  the  MMU  and  change  the 
attributes  to  allow  the  CPU  access.  Unload  removes  the 
segment  base  address,  inhibits  CPU  access  again  and  also 
retrieves  the  changed  bit  from  the  attribute  field.  This 
changed  bit  is  set  when  a  segment  is  written  and  is  used 
by  the  Memory_Manager  to  decide  if  the  segment  can  be 
overwritten  or  if  it  must  be  written  back  to  secondary 
storage.  A  variant  of  Load  and  Unload  is  needed  by  the 
Memory_Manager  when  doing  a  local  to  global  move. 

Swap_MMU  is  called  from  the  Traff icJJontroller 
and  is  a  result  of  the  scheduling  algorithm  being 
executed.  In  the  general  case  a  process  swap  would  occur 
on  the  virtual  processor  as  a  result  of  this  call.  In  the 
Archival  Storage  System,  there  are  only  two  processes 
which  are  allowed  to  run  on  a  virtual  processor:  1)  the 
loaded  process  or  2)  the  Idle  process.  An  MMU  swap  will 
still  occur  conceptually  when  the  idle  process  is  loaied 
because  it  has  an  MMU  image  just  as  any  other  process. 
Actually  the  idle  process's  MMU  image  is  exactly  the  sane 
as  the  loaded  process,  so  a  physical  swap  does   not   take 

place. 

Other  service  calls  will  be  made  to  tie 
InnerJTraff ic_Con troller  from  the  Memory_Manager  ani 
I/C_Manager  but  are  not  detailed  here.  Software  faults,  as 
discussed  in  O'Connell  and  Richardson  [5],  are  net  needed 
in  this  design. 

S.   Memory  Manager  Module 
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The  Memory_Manager  is  a  non-distributed  Kernel 
process  and  is  responsible  for  managing  the  real  memory 
resources  of  the  system.  The  real  memory  of  the  system  is 
both  main  memory  (random  access)  and  secondary  storage 
(non-random  access).  The  Memory_Manager  could  be  part  of 
the  distributed  Kernel  in  the  Archival  Storage  System 
since  it  is  designed  for  a  single  microprocessor;  however, 
the  process  abstraction  is  used  to  maintain  the  "family 
member"  character  of  the  design. 

a.   Memory  Management  Scheme 

The  two  main  tasks  of  the  Memory_Manager  are 
to  bring  segments  into  memory  (In)  or  remove  segments  from 
memory  (Out).  Partitioned  allocation  is  the  scheme 
employed  to  manage  the  memory  resource.  Each  loaded 
process  is  given  a  partition  of  linear  contiguous  real 
core  and  is  required  to  manage  (via  calls  to  Swap_In  and 
Swap_0ut )  the  partition  (its  linear  virtual  core)  in  any 
way  it  chooses.  The  Memory_Manager  checks  each  'In' 
request  against  the  process's  allocation  to  insure  that 
the  allocation  is  not  exceeded  and  to  insure  that 
previously  allocated  memory  is  not  overlayed. 

When  a  shared  segment  is  not  writeable  (i.e., 
write  permission  has  not  been  given  to  any  process^,  the 
design  allows  multiple  copies  (one  per  process)  of  the 
segment  to  exist.  This  frees  the  Memory_Manager  from  the 
task  of  moving  the  segment  to  "processor  global  memory, 
requesting   that   all   MMU  images  be  updated,  and  reserves 
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global  memory  for  segments  which  are  shared  and  writeable. 
Furthermore,  the  space  that  can  be  saved  by  having  one 
copy  would  not  be  usable  by  the  processes  which  are 
sharing  the  segment,  since  each  process's  Supervisor  would 
still  have  the  segment  in  its  virtual  core. 

If  a  segment  is  to  be  shared  and  is  writeable, 
then  the  Memory_Manager  must  move  it  to  global  memory  [5] . 
This  insures  that  all  users  are  sharing  the  same 
information.  Again,  the  actual  location  of  the  segment  is 
invisible  to  the  sharing  processes.  More  memory  is 
allocated  to  the  segment  than  it  actually  uses:  viz.,  one 
copy  per  sharing  process.  However,  the  alternative  to 
using  memory  is  a  complex  algorithm  for  dynamically 
reconfiguring  the  mapping  of  each  partition  whenever  a 
shared  segment  is  relocated  in  memory.  The  tradeoff  of 
memory  size  for  complexity  is  indicated  in  this 
application.  Segments  are  placed  in  memory  within  the 
appropriate  partition  at  the  location  specified  by  the 
Supervisor  call  to  Swap_In.  A  simple  bit  map  lenown  as  the 
Memory_Allocation_Map  (figure  27)  is  used  to  indicate 
which  parts  of  memory  are  available  for  use.  Each  bit  of 
the  map  corresponds  to  a  256-byte  page  of  memory.  The  ter-n 
page  is  not  used  here  in  the  classical  sense,  but  is  used 
to  indicate  a  block:  of  physical  memory.  Segments  cannot  be 
divided  into  pages  scattered  through  core,  bat  must  be 
allocated  to  contiguous  memory  locations. 

The  primary  database  of  the  Memory_Manager   is 
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the   Active_Segment_Table.   It  provides  the  Memory_Manager 
with  the  information  necessary  for  managing  all   segments 
in  the  system  which  are  active. 
b.   Active  Segment  Table 

There  are  two  sections  of  the 
Active_Segment_Table  (AST).  That  portion  of  the  AST  which 
contains  systemwide  information  is  known  as  the 
Global_Active_5egment_Table  (G_AST).  Every  active  segment 
in  the  system  will  have  an  entry  in  the  G_AST.  The 
Memory_Manager  also  maintains  a  portion  of  the  AST  per 
physical  processor  as  the  Local_Active_Segment_Table 
(L_AST).  Only  those  segments  active  within  the  physical 
processor  will  be  in  the  L_AST. 

When  a  segment  is  *Made_£nown"  it  becomes 
active  and  will  have  an  entry  in  the  G_AST  (figure  29)  and 
in  the  appropriate  L_AST  (figure  29).  The  concatenation  of 
the  segment's  Uniaue_ID  and  the  index  to  the  segment's 
entry  in  the  G_AST  form  the  AST3_#  which  is  the  'handle"' 
passed  by  the  ^emory_Manager  for  identifying  a  specific 
active  segment.  When  the  Memory_Manager  uses  the  'handle" 
to  enter  the  G_AST,  it  uses  the  Sntry_#  of  the  ASTI_* 
portion  as  the  index.  In  the  general  case  (e.g.,  demand 
ac tivati on/deactivat ion) ,  the  Unique_ID  of  the  "handle"  is 
then  compared  with  the  Unique_ID  found  in  the  G_AST  entry. 
If  the  identification  check  results  in  a  mismatch,  the 
G_AST  must  be  searched  using  the  Unique_ID  as  a  <.ey  to 
find   the  correct   entry.   This   procedure   is   necessary 
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"because  it  is  possible  that  a  segment's  entry  could  be 
moved  in  the  G_AST  before  all  processes  could  be  notified 
of  the  new  AST5_#.  If  this  occurred  and  a  check  was  not 
made,  an  unauthorized  access  could  then  take  place.  If  the 
match  is  successful  when  first  checked,  the  proper  entry 
has  been  found.  In  this  design  all  known  segments  for  all 
processes  are  active  so  this  problem  cannot  occur. 

Since  the  G_AST  is  a  systemwide  resource  a 
lock  must  be  used  on  the  G_AST  to  prevent  a  race  condition 
from  occurring  [11].  The  mechanism  used  in  the  design  is  a 
locked/unlocked  flag.  Synchronization  on  the  lock  is 
inherent  in  the  functioning  of  the  Pemory_Manager  's 
Signal_Message_Queue .  Note  that  this  mechanism  will  not 
work  if  the  design  is  extended  to  include  more  than  one 
processor  in  the  system  sharing  the  single  S_AST. 

The  Global_Address  field  is  used  only  if  the 
segment  is  located  in  global  memory.  If  it  is  null  the 
address  can  be  found  in  the  L_AST.  The  Connected_?rocesses 
field  is  a  bit  map  signifying  which  processes  currently 
have  the  segment  active. 

The  Written  flag  is  used  to  retain  a  written 
bit  when  a  process  Swaps_0ut  a  segment  which  is  shared  and 
writeable.  For  example:  Processes  A  and  B  are  sharin*  a 
segment  and  Process  A  has  write  permission.  A  has  written 
in  the  segment  and  now  wants  to  deactivate  the  segment. 
Process  B  is  still  using  the  segment.  When  A  requests  the 
Deactivate,    the   Written   bit   is   passed   tc    the 
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Memory_Manager .  But  since  B  continues  to  use  the  segment, 
the  Memory_Manager  will  only  reset  Process  A's  flag  in  the 
Connected_Process  field.  The  Written  bit  is  then  logically 
ORed  with  the  G_AST_Writ ten_Flag.  When  B  then  Deactivates 
the  segment,  the  Written  bit  it  passes  indicates  that  a 
write  has  not  taken  place.  An  error  would  have  occurred  if 
the  Written  bit  from  Process  A  had  not  been  saved  since 
the  Memory_Manager  does  not  write  an  unmodified  segment 
back  to  secondary  storage. 

The  Writeable  flag  is  set  whenever  any  process 
has  write  access  to  the  segment.  This  is  the  key  flag  for 
deciding  (at  the  time  activation  is  requested)  if  the 
segment  must  be  placed  in  global  memory.  It  cannot 
conveniently  be  used  to  provide  an  alternative  to  the 
scenario  presented  above  for  Written.  Consider  that 
Processes  A,  B,  and  C  all  have  writeable  shared  access.  If 
A  Deactivates  after  writing,  the  Menory_fiana.?er  could 
write  back  to  secondary  storage  at  that  time,  (assuming 
the  proper  synchronization  was  used  to  prevent  B  or  C  from 
writing  while  the  transfer  took  place).  Then  when  3  or  C 
Deactivated  after  writing,  another  write  to  secondary 
storage  would  take  place.  Thus  at  least  one  unnecessary 
action  took  place. 

The  Alias_Table_ASTE_#  will  be  null  unless  the 
segment  is  a  mentor  segment.  Whenever  a  mentor  segment  is 
made  active  its  A lias _T able  segment  is  made  active  at  the 
same  time  and  will  be  assigned  an  ASTS_*.  (The  Alias_Table 
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is   a   Memory_Manager   object.  The  Alias-Table  is  actually 
implemented  as  a  collection  of  segments.) 

In  the  general  case  with  demand 
activation/deactivation,  the  #_Entries_Active  is  a  field 
which  is  used  for  Alias_Table  entries  only.  An  Alias_Table 
segment  must  remain  active  as  long  as  any  of  its  entries 
are  active,  although  it  need  not  remain  in  main  memory. 
The  #_Entries_Active  is  a  counter  which  is  incremented  any 
time  an  Alias_Table  Entry  is  activated  and  decremented 
when  an  Alias_Table  Entry  is  deactivated.  Thus  the 
Alias_Table  frame  can  be  deactivated  only  when  the 
Connected_Processor  map  of  the  mentor  segment  and  the 
#_Entries_Active  both  become  zero  or  null.  (Note  that  the 
Connected  Processor  Map  of  the  Alias_Table  segment  will 
always  show  only  the  physical  processors  wnose 
Memory_Manager  has  the  Alias_Table  in  its  address  space.) 
In  this  design  all  known  segments  are  active  so  these 
explicit  checks  upon  deactivation  are  not  required. 

The  remaining  field  of  the  G_AST  is  the 
Page_Table_Address .  The  Page_Table_Address  is  the  location 
in  secondary  storage  of  the  page  table.  The  ?age  table  in 
turn  provides  the  location  of  the  segment. 

The  L_AST  portion  of  the  AST  is  maintained  per 
physical   processor   and   should   not   be   confused  with  a 
distributed   data   structure   since    the    L_AST    is 
Memory_Manager   data    structure   and   not   part   of 
distributed  Kernel.  It  is  searched  by  Virtual_?rocessor_ID 
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and  segment  Uniaue_ID.  The  remaining  four  fields  are 
Access,  Absolute_Address ,  Size,  and  Sesment_#.  The  Access 
is  the  read  or  read/write  access  of  the  segment  available 
for  use  in  moving  between  local  and  global  memory.  The 
Absolute_Address  is  the  location  of  the  segment  in  main 
memory.  If  Absolute_Address  is  null,  the  segment  is  on 
secondary  storage  and  has  not  been  moved  to  main  memory. 
c.   Aliasing  Scheme 

The  Memory_Manager  also  provides  the  aliasing 
service  for  the  system.  Each  segment  which  exists  in  the 
Archival  Storage  System  has  a  Unique_ID.  This  Unique_ID  is 
an  integer  which  uniauely  identifies  each  segment.  It  is 
chosen  from  a  large  list  of  integers.  Since  the  data  type 
is  a  longword,  the  list  contains  more  than  four  billion 
unique  integers.  To  prevent  a  communication  path  from 
existing  when  a  segment  identification  must  be  passed  out 
of  the  Kernel,  an  alias  is  provided  which  virtualizes  the 
Unique_ID.  When  a  process  wishes  to  create  a  new  segment, 
it  must  pass  the  Kernel  a  Mentor_Segment_*  and  a  desired 
Sntry_#.  The  mentor  segment  can  be  any  segment  the 
Supervisor  wishes,  but  an  entry  for  the  mentor  must  be  in 
the  Known_Segment_Table  of  the  process.  The 
Segment_Manager  then  loo»cs  up  the  ASTE_*  of  the  segment 
and  Signals  the  Memory_Manager  with  the  ASTE_*  and 
Entry_#.  The  Memory_Manager  maintains  a  fiat  file  system 
known  as  the  Alias_Table  (figure  30)  which  is  systemvide. 
Every  active  mentor  segment  has  an  ASTE_#  for  a  segment  of 
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the  Alias_Table.  When  the  Memory_Manager  receives  a  Signal 
which  requires  use  of  the  Alias_Table,  the  Memory_^anager 
brings  the  appropriate  Alias_Table  segment  into  memory. 
The  Entry_#  is  then  used  as  an  index  into  the  Alias_Table 
where  the  Memory_Mana*er  can  determine  the  Unique_ID  and 
physical  attributes  of  the  indexed  segment.  A  segment 
exists  for  each  entry  in  the  Alias_Table. 

The  attributes  found  in  the  Alias_Table  are 
the  segment  Size,  the  location  of  its  secondary  storage 
Page_Table,  the  segment  Access_Class,  and  the  secondary 
storage  page  table  of  its  Alias_Table  segment  if  it  is  a 
mentor  segment.  AliasJTable  storage  is  allocated  when  the 
first  reauest  for  an  Alias_Table  entry  is  made,  and  is 
deallocated  whenever  the  segment  is  empty.  The 
Memory_Manager  will  not  honor  a  request  to  delete  a 
segment  if  it  has  an  Alias_Table  segment.  If  this  deletion 
were  allowed,  storage  space  would  be  lost  forever  since 
the  Alias_Table  segment  of  the  mentor  segment  and  any 
segments  referred  to  by  that  Alias_Table  segment  would  not 
be  recovered. 

d.   Storage  Allocation 

The  Memory_Manager  is  responsible  for 
controlling  storage  media  as  well  as  main  memory.  The 
storage  hardware  for  this  design  is  anticipated  to  be  a 
type  of  hard  disk:  using  the  Winchester  technology. 
However,  the  design  may  be  initially  implemented  on  an 
eight-inch   "floppy"  disk  drive  using  the  IBM  standard. 
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single  density  format.  Using  this  standard,  a  single  disk 
has  77  tracks  of  26  sectors  each  available  for  storage. 
Each  sector  stores  128  bytes  of  information. 

Since  the  Z8000  hardware  allows  segment  sizes 
in  multiples  of  256  bytes,  it  is  convenient  to  establish  a 
"page"  size  as  256  bytes.  Using  this  scheme,  a  page  can 
then  be  stored  in  two  sectors  of  the  disk.  A  page  then 
becomes  convenient  as  the  size  of  a  page  table.  The  page 
table  is  used  to  record  the  location  of  each  page  of  the 
segment  on  the  disk.  If  the  location  of  each  page  is 
stored  in  unpacked  form,  a  total  of  128  page  locations  can 
be  stored  in  a  page.  Note,  however,  that  this  scheme  uses 
only  11  of  the  16  bits  which  can  contain  information  (7 
bits  for  the  track  index,  and  4  for  the  sector  index),  and 
can  easily  be  reduced  to  10  bits  since  every  other  sector 
is  not  explicitly  indexed.  This  means  that  1024  pages  can 
be  addressed  by  one  page  of  a  ?age_Table  and  is  adeauate 
to  store  the  maximum  size  segment  (256  pages)  allowed  by 
the  Z8000  hardware. 

A  free  page  bit  map  is  needed  in  order  to 
record  which  pa^es  on  the  disk  are  available  and  which  are 
allocated.  This  will  also  reauire  one  page  on  the  disk. 
This  scheme  allows  the  disk  space  to  be  allocated  to 
segments  from  the  "free  list"  and  does  not  require  complex 
compaction  algorithms.  If  other  forms  of  storage  media  are 
used  they  can  be  easily  adapted  to  this  scheme. 
9.   Input_Output  Manager  Module 
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The  I/C_Manager  is  the  non-distributed  Kernel 
process  which  is  concerned  with  moving  information  across 
the  boundaries  of  the  Archival  Storage  System.  It  manages 
the  input  and  output  ports  of  the  system  as  a  resource  in 
much  the  same  way  as  the  Memory_Manager  handled  the  memory 
resource.  The  I/0_Manager  would  use  an  Attach_Table  to 
virtualize  the  system  ports.  While  the  I/0_Manager  is  a 
process  in  the  general  case,  it  can  be  designed  and 
implemented  as  a  distributed  Kernel  function. 
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Ill  .   CONCLUSION  AND  FOLLOW  ON  WORK 

The  detailed  design  of  the  Security  Kernel  for  a  data 
warehouse  has  teen  presented.  This  design  is  suitable  for 
implementation  on  a  Zilog  Z9000  microprocessor-based 
system.  A  minimal  subset  of  a  family  of  secure  operating 
systems  has  been  demonstrated  to  exist  and  can  be 
implemented  on  microprocessor  hardware  which  is  available 
today.  This  design  also  shows  the  feasibility  of  an 
Archival  Storage  System  that  can  be  the  nucleus  of  a 
distributed,  multi-microprocessor  computer  system  by 
providing  archival  storage  with  multilevel  security. 

The  design  illustrates  the  utility  of  modern  software 
engineering  techniques.  A  loop-free  structure  was 
maintained  as  a  design  goal,  preserving  the  ability  to 
modify  a  module  without  introducing  change  in  any  other 
module.  An  explicit  process  structure  simplifies  the 
design  for  asynchronous  functions.  Functionality  of  this 
family  member  can  be  extended  by  including  additional 
primitives  from  the  larger  set  of  primitives  described  by 
O'Connell  and  Richardson  [5] . 

Security  of  information  was  a  primary  goal  throughout 
the  design  process.  A  mathematical  model  was  used  as  a 
foundation  for  the  Kernel  to  insure  properly  designed 
security.  A  multilevel  security  capability  is  included  for 
the  storage  system.  Furthermore,  on  this  base  a  complete, 
rrultilevel  secure,  distributed  "system"  can  be  constructed 
with   the  storage   system  as  the  only  component  requiring 
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multilevel  security. 

While  designed  for  a  single  microprocessor  with  memory 
management  unit  support,  the  structure  of  the  hi*h  level 
design  which  allows  configuration  independence  was 
preserved.  The  same  concepts  for  reducing  bus  contention 
in  a  multiprocessor  system  while  providing  data  sharing 
were  used  and  can  he  easily  extended,  e.g.,  for  increased 
processing  capacity  to  serve  a  large  number  of  higher 
bandwidth  hosts  . 

Implementation  of  the  Archival  Storage  System  is  an 
area  for  further  work.  The  distributed  Kernel  data 
structures  and  procedures  are  described  in  this  thesis. 
Additional  effort  will  produce  compilable  implementation 
code  and  from  this  code  generate  a  loadable  system.  The 
Kernel  non-distributed  processes  for  I/C  and  physical 
memory  management  have  been  briefly  presented  and  more 
detailed  design  will  be  needed  prior  to  implementation. 
The  Archival  Storage  System  design  is  a  minimal  family 
member.  Additional  services  to  the  Supervisor  and 
generalization  of  the  simplifying  assumptions  (e.  g.,  to 
interface  to  multilevel  hosts)  are  major  areas  where 
continued  research  is  indicated. 

After   implementation   of   the   storage    system, 
substantial   work  is  necessary  in  performance  evaluation. 
Hardware   choices   have   been   primarily   left 
implementor.   Since   many   of    the   software   ie^ 
imolications  on  efficiency  are  unknown   at   the   present 
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time,   fine-tuning   of   both  hardware   and   software  will 
result  in  better  system  performance. 
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APPENDIX  A  -  GATE  KEEPER  LISTING 


Gate_£eeper  Procedure 

Type 

Parameter_Table_Entry 


Record    [Function_ Address    Longvord 
N0_Cf _?arameters    Integer 
Para_l_Length    Integer 
Para_2_Length    Integer 


?ara_n_Length    Integer] 

Local  {Initialize    local   variables! 

Valid    :=   1 
Invalid    :=   0 
Index    :=   8 

?arameter_Table    Array    [>ax_Function_Code 

?arameter_Table   Entry] 
:  =  [[«Traff  i  c_C on t roller >>Blccic"En try  ,  1]  , 
[<<Traff ic_Controller>>Wake_Up_Entry,3]  , 
[<<Seg:nent_Manager>>Creat  e_Entrv  f  5]  , 
[<<Segment_Manager>>Delete_Sntry ,3] , 
[<<3egment_Manager>>i*ake_Kr.  own_Er.  try  ,5]  , 
f<<Segment_Manager>>Termina te_Entry ,2] , 
[<<Seg!nent~^anager^>3wap_In_Entry ,3]  . 
[<<Segment_Manager>>Swap_Out_Entry  ,2]] 
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Entry 

DI  NVI,VI       fDisable  interrupts! 
PUSH  GRR14,R0        !Save  user  registers! 
PUSH  0RR14,R1 
PUSH  (?RR14,R2 
PUSH  GRR14,R3 
PUSH  (?RR14,R4 
PUSH  9RR14.R5 
PUSH  GRR14,R6 
PUSH  GRR14,R7 
PUSH  0RR14.R3 
PUSH  0RR14,R9 
PUSH  GRR14.R10 
PUSH  @RR14,R11 
PUSH  0RR14,R12 
PUSH  GRR14.R13 

LDCTL  R2,NSPSEG        !Save  user  stack  pointer! 
LDCTL  R3,NS?CEE 
PUSH  0RR14,R2 
PUSH  (?RR14,R3 

EI  NVI,VI         lEnables  interrupts! 

VALIDATE:  DO       JCheck  location  of  arguments  for  user 

read/write  access! 

LDL  «DI ST  KERNEL  ID>>ARGUMENT  POINTER, RR2 

CALL  CHEC5_ADDRESS_SPACE 
IGet  return  value! 

LD?  RH0,<<DIST_KERNEL  ID>>VALIDITY_CCBE 

LDB  RH1, VALID 

CPE  RH1.RE0 

I?  NE  THEN  EXIT  FROM  VALIDATE   IRetum  if  invalid! 

ELSE  LDL  RR2,  «DIST_KERNEL_ID>:ARGUMENT_?CINTZ?. 
LD3  RH0, INDEX 

EI 
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MOVE_STACK:  DO     !Move  argument  list  to  Kernel  work:  space! 
CPB  RH0,#0 
IF  EQ  THEN  POP  R4,GRR2 

PUSH  0RR14.R4 
D*C  RH0 
ELSE  EXIT  FROM  MOVE_STACK 
FI 

REPEAT  FROM  MOVE_STACK    ILooo  until  all  -roved! 
OD 
CALL  FUNCTION:  DO 

LD  FUNCTION_CODE,(?RR14(#24)  IRetrieved  from  system  call 

instruction  on  system  Stack  1 
LD  R6, MAX  FUNCTION  CODE 
C?  R6,FUNCTIGN_CCDE 

IF  GT  TEEN  LD  LDL  RR10,«DIST  KERNEL  ID>>MESS.».GZ  POINTER 
LD  R2JNVALID  FUNCTION  CODE 

LD  @RR10(0)tR2    !?ut~error  code  into  message! 
EXIT  FROM  CALL_FUNCTION 
ELSE  LD  R6,0RR2( NUMBER  OF  ARGUMENTS) 
! Check  number  of  oarameters! 
CP  R6,FUNCTI0N_TA3LE[FUNCTI0N  CODE  ,  NO  OF  ARGUMENTS] 
IF  EQ  T^EN  CALL  FUNCTION  TABLE  [FUNCTION_CODE  .FUNCTION 
ELSE  LDL  RR10,<<DI3T_KERNEL_ID>>MESSAGZ_?C:MTER 
LD  R2  , 1  NV  ALI  D_  A?.GUMENT~L  I3T 
LD  GRR10(0),R2 
EXIT  FROM  CALL_FUNCTICN 
FI 
FI 
OD      !END  OF  CALL  FUNCTION  LOOP! 
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LDB  RH1, INDEX      !Zero  out  user  argument  list! 
ZERO_OUT:  DO 

CP  RH1,#0 

IF  NE  THEN  POP  R2,0RR14 

EEC  RH1 
ELSE  EXIT  EROM  ZERO_OUT 
FI 

REPEAT 
OD 
LDL  RRS,<<DIST_KERNEL_ID>>MESSAGS_?0INTER 

LDL  RR4,0RR14(NSTACK  POINTER) 

LDB  RH2,#0 
LDB  RH1,#9 
MOVE_RET_MSG:  DO     !Put  message  back  in  user  area! 

CP  RH1,#0 

IE  NE  THEN  LD  R2,0RR8(RH6) 

PUSH   0RR4.R2 
INC    RH2 
DEC    RH1 

ELSE    EXIT    EROM    MOVE_RET_MSG 

FI 

REPEAT 

OD 
OD     !END  OF  VALIDATE! 

DI  NMI,VI     IDisable  interrupts! 
POP  R3.GRR14     !Restore  user  registers! 
POP  R2,GRR14 
LDCTL  NSPSEG,R3 
LDCTL  N1S?0EF,R2 
POP  R13,(?R?.14 
POP  R12.GRR14 
POP  R11,(?RR14 
POP  R10.GRR14 
POP  R9,ORR14 
POP  RS.GRR14 
POP  R7,@RR14 
POP  R6,0RR14 
POP  R5,3RR14 
POP  R4.0RR14 
POP  R3.0RR14 
POP  R2,3RR14 
POP  RlfGRR14 
POP  R0.0RR14 

EI  MMI,VI     lEnable  interrupts! 
IRET      JRestore  pre-call  cpu  state! 
End  Gate  Keeuer 
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APPENDIX  B  -  SUCCESS  AND  ERROR  CODES 


CODE 


ENTRY  POINT 


Invalid_Function_Code 
Invalid_Argument_Code 
Mentor_Seg_Not_Found 

Not  Allowed 


Not_Compatible 
Segment_Too_Large 
No_Segment_#_Avail 
Segment_Found 


Segment_Not_Known 

Segment_In_Core 

Kernel_Segment 

Invalid_Segment_# 

Swapped_In 

Swapped_Out 

Queue_Empty 

Queue_Overf low 

Inserted 


G-ate_Keeper 

Gate_Keeper 

Create_Segment 

Delete_Segment 

Create_Segment 

Delete_Segnent 

Make_£nown 

Waice_Up 

Create_Segment 

Create_Segment 

Ma.-ce_Known 

Mak:e_Xnown 

Swap_In 

S wap_Out 

Terminate 

Terminate 

Terminate 

Terminate 

5wap_In 

Swap_Out 

Block 

Wake_Up 

Wake_Up 
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CODE 
Not_Related 
Great  er_Tlian 
Less_Than 
Equal 


ENTRY    POINT 
^on_Disc_Securl ty 

Non_Disc_Security 
Non_Disc_Security 
Non   Disc    Security 
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